Git Basics

How to quickly use Git for day to day developments

...


And Stash

Leverage Git on the Enterprise

Created by François D'Agostini / @DagoFrancesco

Original presentation on GitHub

What is Git ?

Distributed Version Control

  • Speed
  • Simple
  • Non Linear Development
  • Fully Distributed
  • Large Projects

Snapshot based, not deltas

Different from CVS, svn...


Git Configuration 


    git config --global user.name "François D'Agostini"
    git config --global user.email "fdagosti@nds.com"
  • --system: /etc/gitconfig
  • --global: ~/.gitconfig
  • default: repo/.git/config

colors in Linux:

git config --global color.ui always

Creation of a repo

  • No need for network
  • Can do a lot locally on PC
  • Best for testing

Git init: repo + working directory
git init --bare: Repo only
git clone:From an existing repo

Example: first commit

mkdir git-tests
git init john.git
git config user.name "john Doe"
git config user.email "john@example.com"
echo "first line from John" > file1
git add file1
git status
git commit -m "initial commit from John"

Another Commit

cat >> file1
Second Commit from John
git commit -a -m "another commit "

Working directory, indexes and commits

Viewing Commits history 

git log
        --decorate
        --graph
        --stat
        --oneline
        -n
...lots of other options !!

git blame: one files only
gitk: for graphic visualization
same options as git log

Commits history (2)

git show: details about a commit by default, shows the detail of the most recent commit
git show-branch: show details about the current branch

Handy Alias

git config --global alias.graph "log --decorate --graph --oneline"

Viewing Commit differences

git diff: differences between the working directory and the index
--cached: between the index and the most recent commit
HEAD: between the working directory and the most recent commit

cancellation, restoration, cleaning

  • git reset: cancels changes about to be commited in the index
    • --hard: changes also the working directory
  • git checkout: cancels changes made to working directory compared to index
  • git clean: deletes files not followed by Git.
    • -f option to really delete them
    • -n to simulate
  • .gitignore file: to avoid Git to track useless files

Branch management

  • A Branch is just a pointer to a commit
  • nothing fancy
  • very lightweight
  • very similar to "tags"
  • stored in .git/refs/[heads|remotes|tags]
  • Default branch name: master

Branch management (2)

  • git branch: list branches
    • -r: remote branches as well
    • -a all branches
  • git branch dev: create branch "dev"
    • Does not change the current branch
  • git checkout dev: move the current branch to the "dev" branch
    • -b: create the branch while switching to it

Merging

  • git merge dev:merges "dev" branch into current branch
    • does not destroy "dev"
  • git branch -d dev:deletes the "dev" branch
    • only deletes the pointer
    • can be deleted only if the branch is accessible from the current branch
    • This is usually what is needed after merging. The old "dev" pointer is no longer useful
    • in case of future branching, a new branch can be created

Conflict Resolution

  • git merge can lead to conflicts if the same file has been modified in two branches
  • manual conflict resolution is needed on this files
  • conflict markers are added by git and need to be removed by the developper
  • git add on the conflict files
  • git commit to end the merge
  • and of course, delete the merged branch
  • if conflict resolution is too complex:
    • git merge --abort: restores the working directory to the state it was prior to merge

Remote repositories

  • git remote: lists all remote repos linked to the current local repo
  • git remote add name url: adds the specified url as a remote repo to the local repo
  • No need in case repo has been created with git clone
  • git push repo: push local commits on the current branch to the same branch on the remote repo
    • warning: the remote repo must already have the same branch, else use git push repo branch

Remotes: fetching and pulling

  • There is a separate copy of the remote commits separated from the local branch
    • Can be seen using git branch -a
  • this means that the remote and the local copy can easily be compared
  • git fetch repo: updates the local copy of the remote repo
  • git pull: like git fetch, but also merges the remote commit into this repo's branch
    • this one can lead to conflicts

Git Rebase

  • When fetching commits from remote repos, there are two ways to merge them:
    • regular merge: it will create a new commit every time
    • rebase: it will not create a new commit
  • allows to change the commits that were not published to have new parents
  • very handy when you need to integrate other people changes but continu your work
  • use: git rebase branch
  • git pull --rebase: will use the reboase algorithm in case of conflicts instead of merge

Stash: Save your work while switching context

  • Allows to save your current context and switch work
  • Then, you can restore the exact state back
  • git stash save messages: stores the working director and the index into a stack
  • git stash list: lists all the saved stacks
  • git stash show: shows the details of a stack item
  • git stash pop: pops a state and applies it on the current working directory
  • git stash drop: removes an item on the stack

Stash (2)

  • warning, stashing does not store the branch state
  • This means that you can recover your state on any branch
  • popping a state can create conflicts that needs to be merged
  • if a pop failed because of a conflict, it will need to be removed manually

Git Hosting in the Company

Stash

Different from git stash seen previously !!

Why need a git hosting tool?

  • Git alone is not sufficient
  • To improve knowledge sharing
  • to improve code visibility
  • to get the code out of the darkness !!

Stash caracteristics

  • Structuring projects, repos and roles
  • Browse files, branches, commits and tags
  • Code Reviews concepts: Pull requests
  • Repos forking
  • private repos
  • Jira linking

Project Structures

  • Stash organized by projects that handles multiple repos
  • permissions are based on projects and repos. Allows for decentralized admin
  • users have roles: project creators, admins, system admins, writer
  • Soon, anonymous mode

File browsing

  • Can browser any file and see source code
  • Allows to change branches and tags
  • Can have details of each commit
  • browse list of commits and log
  • markdown support to explain source code organization

Pull requests

  • Implements best practices with respect to code review
  • Allows anyone to create a branch, make some code and ask for its merge
  • Branch permissions allows to control commits
  • Pull requests allow to review, make comments, ammend new commits, see diffs...
  • Anyone can watch a pull request and be notified
  • Pull requests can be declined or accepted

Forking

  • fork a repo into another repo, but keep history
  • allows for later merges

Private repos

  • Develop your own projects
  • can show or hide repos to others

Jira link

  • Allows to link Git commit to Jira issues
  • from a Jira issue, see all related commits
  • with Git hooks, you can force it

Branching strategies with Git

  • Git is small tool that does not come with a whole environment and rules (think Clearcase...)
  • Git is versatile and can be used in a dozen of different ways
  • Git itself does not enforce how to use branches and how to work as a team. It keeps this open
  • But how a serious company is supposed to use git for all its projects without going messy ?

We need best practices !!

Git Flow

  • Standard usages of branches when working with Git
  • Used in Big projects, with many developers working on it

Main caracteristics

  • 2 long lived branches : Develop and master
  • 3 short lived branches: Feature, Release and HotFix
  • The master branch is restricted to commit by one or two people
  • The Develop branch is restricted to senior developers
  • New code is added through Feature branches only

Steps to follow

  • Create a Feature branch, name it to the story/feature you are working on
  • once you are happy with your features, you create a pull request to merge it

Steps to follow (2)

  • When a release must be done, use a temporary release branch
  • The Master branch is used only for "stable" version commits. Any commits on master should have a Tag
  • If a bug is found on Master, a "HotFix branch is created to correct it and merge it back on master