Git is a version control system that most software developers would have heard of. It’s the tool of choice for the team behind the Linux kernel and comes with the associated prestige and sets a high floor for the technical competence of its users.

Git has a steep learning curve as it’s incredibly flexible and the web is splattered with inconsistent information about using it. The trouble is that often the people that write and talk enthusiastically about Git are hardcore programmer-types that espouse attributes that aren’t really important or valuable out of their context (“free, open source and distributed”). If you ask whether it increases productivity compared to the alternatives? Then yes, it helps, a lot.

What is it exactly?

Git is a content version control system. It allows the users to keep multiple versions of a set of files and comfortably switch between versions and merge difference versions together. It also aids with the collaboration of those file sets. I’m not going to promote the importance of this activity as it’s an assumed necessity. Git’s point of difference compared to other systems is that it makes this comfortable to do.

For years I didn’t see any strong reason to move to Git from Subversion. I leaned about it but saw no real benefit of its distributed model and related noise. Our new contractors were using it so we switched to be consistent with their toolset. Now I love it.

What’s important about Git?

Compared to the alternatives I’m familiar with, Git increases the productivity of your team members when they need to manage multiple versions of their stuff. By stuff, I mean the code and config for developers, images and documents for designers. It’s a content version system for their working set. Critically, especially for developers, is that allows users to quickly switch context between the set of code they’re currently working with to any other branch or version, in a moment, with no fear of losing what their working on, and no fear of corrupting other versions. This is a significant time-saver. They’ll love it.

How so? By example

Let’s assume you have a master copy of your code (I’m going to use code now, but I mean any set of files). I’m also using the terminal version of git as any but there’s good graphical tools too.

git checkout -b myNewFeatureBranch master

Your team member is going to start working on a new feature. By convention, they always create their own branch off the master copy.

This branch is local to them. No other developers can see it, although it can be shared if they wish. The developer works away changing some code in their local branch when he’s interrupted by another developer. There’s something broken in the master copy that needs to be fixed immediately as it’s blocking progress. The developer stashes his current changes aside and switches to a new branch off master. This takes only a few seconds.

git stash
git checkout -b myFixBranch master

That stash command places the incomplete work in a temporary stack with out committing the changes. It’s good they don’t have to commit changes to their local branch if they’re not ready to (although that was possible with a quick git commit instead of stashing). The developer applies his fix and merges this back into master. This time he’d better share his changes with the other developers by pushing it upstream.

and they get back to work…

git checkout myFeatureBranch 
git stash pop

myFeatureBranch is still at their last commit. Popping their stash brings back their temporary edits on top of that. Note also that the myFeature branch doesn’t contain the changes made in the myFix branch. They’ll be merged together later in the master branch, or can be brought in now without risk if needed (via git merge or git cherry-pick ).

Those few commands provide a really nice workflow for individual developers. They can have several different versions of the code in work worked, on the same machine, in the same directory, without fear of corrupting or losing track of what they’re doing. There’s many legitimate reasons for developers to have a few things going at once, and Git handles this elegantly.

How does it work?

Despite most Git documentation being incredibly verbose, the details aren’t really that important. Every commit has a unique ID and Git combines series of commits into different views for branches. Conflicts do occur, but the practice of creating lots of short-lived branches that are merged regularly minimizes the magnitude of conflicts and provide good traceability to the intent of the changes.

The developer always works against their own local copy of the code. Their repository can be set up to track another developer’s copy, which is where pulling and pushing come in. By convention, the remote copy may be a centralized master used for releases. Or not. That’s the point of it being technically distributed rather than centralized. The same technique may be used so multiple developers can work on the same feature branch.

The details?

Git has an incredible number of features and options. Sometimes this is one of the detriments of community-driven open-source software; people keep adding features but few have the authority to take them out. However git does have a good authority and seems to be a well-planned tool. There are some good places to learn the fine details.

Git Ready and Stack Overflow are good sources of practical tips, however it’s also valuable to follow a proven Git workflow rather than invent your own. My favourites are:

• nvie.com: A successful git branching model
• Scottchacon.com: Github-flow (identifies problems with the model at nvie.com)

Try it out!