Using Git Efficiently

Git branching

Git is a free and open source distributed version control system. Git is designed very differently from tranditional version control system like Subversion (SVN). It may confuse a SVN user at first. In oder to benefit Git’s effeciency and speed, it’s really important to uderstand it and use it wisely. This article is not a “getting started” tutorial neither a deep discussion of Git, but will provide relevant tips, references, links to help professionals understanding and using Git for their daily work. I suppose that you, my dear reader, have already the basic undersatding on version control system such as SVN or CVS.

Uderstanding Git

first of all, make sure those basics are clearly understood:

Git is distrubuted, you have everything the server has
Git is a story of snapshorts not deltas
Think Git as a filesystem
Git is fast because it works locally most of the time
3 states: committed, modified, and staged
GIT use SHA-1 algorithm to hash cryptographically its contents

This “getting started” documentation explains very well these basics in a simple way. Understanding the differences between Git and SVN in the first place is vital because this is where mistakes often happen. This article explains very briefly the fundamental differences between the two systems.

Now, let’s try Git. If you haven’t installed Git yet, here are links for installing and setup.

Working with Git

This documentation explains very well the basic daily work commands. There is no need to say more, I just sum up the most used commands as following:

Recording changes to the repository

#To begin tracking the README file git add README #To check files states git status #To view last changes git diff #To add everything from current directory to stage git add . #To remove README from the stage but keep it in the working tree git rm --cached README

Viewing commits history

Commit message model

Short (50 chars or less) summary of changes More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here

Undoing Things

Be careful, because you can’t always revert some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong. Anything that is committed in Git can always be recovered. Even commits that were on branches that were deleted or commits that were overwritten with an —amend commit can be recovered. However, anything you lose that was never committed is likely never to be seen again. It’s good practice to commit things regularly.

Working with Remotes

#To show server infomation git remote -v #To add a remote repository, this is something SVN can not do: the same directory manage multiple remote repository git remote add iyunbo git://github.com/iyunbo/iyunbo.git #To get data from the remote projects git fetch [remote-name] #To fetch and merge data from the remote git pull #To upload your data to the remote git push #To inspect a remote git remote show origin

Making Git easier

Here is a BASH script to make Git experience simpler, easier and familiar.

#make git easier to use! wget https://raw.github.com/git/git/master/contrib/completion/git-completion.bash > ~/.git-completon.bash echo "source ~/.git-completion.bash" >> ~/.bashrc git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status git config --global alias.unstage 'reset HEAD --' git config --global alias.last 'log -1 HEAD'

Branching with Git

Branching is the “killer feature” in Git, it changes the way we develop. I still remember how painful to manager a branch with SVN. But with Git, it’s so lightweight that swiching between branches is almost instantaneous. You can read this documentation to know about Git branching. I list out just some important tips:

Understand what branch is in Git is most essential, this documentation helps you understand it very well
Branch & Merge are day-to-day tasks, here is a basic story to show how these things are done

# I am assigned a issue, let me create a new branch and switch to it for working on issue 53 git checkout -b iss53 # Switch back to production because something goes wrong git checkout master # Create a hotfix branch to fix the stuff git checkout -b hotfix # After fixed, I go back to master again and merge the hotfix git checkout master git merge hotfix # After the hotfix version has been deployed, get rid of the merged branch git branch -d hotfix # OK, let's take a break, nice, the bug is fixed and I can go back to work on my unfinished issue git checkout iss53 # It turns out that the hotfix I did is important to my issue too, so merge it from the master git merge master

The above example just shows a simple use case, however the real life work are more complicated and branches are managed by different levels of stability especially when dealing with large projects.

Git branching

In Git it’s common to create, work on, merge, and delete branches several times a day. Comparing to SVN, branches are largely used and encouraged in Git giving its effeciency and simplicity. Remember all those merge, branch operations are managed loacally, no server communication is happening.

See this documentation for Remote Branches management
And this documentation for Rebasing.

Rebasing results in changes as the merge, but offers a cleaner commit history. The following commands are often used when dealing with rebasing.

#To figure out the patches from the common ancestor of the client and server branches, and then replay them onto master git rebase --onto master server client #Now you can fast-forward your master branch git checkout master git merge client #Then rebase and merge server as well git rebase master server git checkout master git merge server #Goodbye merged branches git branch -d client git branch -d server

NEVER, never, never rebase commits that you have pushed to a public repository. This could generate a lot of useless work for everybody of your team

At this point, you should be confortable with Git basic commands and concepts, but for working on real projects, you still need define a workflow model and some rules for your team, here is a list of very good guidelines and practical recommandations:

Yunbo WANG

YW

Using Git Efficiently

Uderstanding Git

Working with Git

Branching with Git

More

Comments