On Using Git Well

Git

For any software project you work on that's larger than trivial you should be using a version control system. And of all the version control systems I've used—CVS, Subversion, Team Foundation, and Git—Git is by far the best (in my opinion).

There are too many articles already describing why Git is a great version control system (e.g., see this blog post). Therefore, I won't get into that here. But I will say that almost all of the open source tools I use are using Git (e.g., NUnit, NSubstitute, OxyPlot, YamlDotNet, Entity Framework).

Git has one major drawback, however. It has a steep learning curve. It took me a while to get Git. I believe that what helped me the most was understanding how Git works under the covers. The book Version Control with Git (O'Reilly Media) was especially enlightening in this.

I'm not going to teach you Git in this blog post, but I'll point you to some resources. I've already mentioned the O'Reilly book above. Another book is Pro Git (Apress), which is available free online. For a very basic introduction to Git, I wrote a tutorial a few years ago. Finally, when you have a specific question, there's Stack Overflow.

"A Successful Git Branching Model"

Recently, I looked for a Git workflow that would help me manage branches for features, bug fixes, and releases. I found the excellent blog post "A successful Git branching model" by Vincent Driessen.

To summarize, you have two main branches: master and develop. Most work happens in the develop branch. If you're ready for a release, say version 1.2.3.4, create a new branch from develop and name it release-1.2.3.4. After your users test it and find bugs, you fix the bugs in that branch, and when it's finally ready, you merge it to both master and develop. Then tag the master branch with the version number.

For development of features that you know will take some time, create a new branch from develop and work on your feature there. When it's ready, merge it back to develop. This allows you (and others) to work on features independently.

Finally, if you need to do a quick fix to a version you've already released, you create a new branch from master (e.g., hotfix-1.2.4.0), make your changes there, and then merge it to both master and develop.

I've been using this workflow for the past few months and I like it very much. I feel like I have better control of my branches. Just so that I don't forget it or skip a step, I printed out the chart of the workflow and posted it on my wall.

Tips

Often, I want to see an overall picture of my branches and their relationships. This is especially helpful if you're using the workflow above. Here's the command I use:

git log --graph --all --decorate --oneline

Rather than typing all that every time, I made an alias. Now I can just type "git lg".

If you use Cygwin, I've found that Git doesn't automatically recognize the carriage return character as an end-of-line character. It's annoying to see a bunch of ^M symbols in "git diff" displays. To fix this problem, use the following configuration setting:

git config core.whitespace=cr-at-eol

Git has many, many commands. I can't keep track of all of them in my head, so I've been writing down those commands I've needed and want to remember here. Most of the time, though, I just do a Google search for something I want to do in Git and often find the answer.