Living with Git, the distributed version control system

I started talking with Filemon about Git, the distributed version control system, in episode 44 of the podcast, but I'd wanted to write about it before we recorded. A lot of things don't occur to you when you're recording, so I decided to devote a few more lines to Git here. I've used Git for the past six months at GoodData and used it quite intensively for about half of that time. I have to say I'm delighted with what it can do. To be clear, I was a very happy SVN user and didn't feel I was missing anything, but Git gave me some genuinely useful things.

Git can work in a decentralized way. Your laptop can be completely disconnected from the network and you can still do your work. Git lets you carry out every repository operation except pull and push, which synchronize with a remote repository. You can work fully offline, meaning you can switch branches, merge, travel through your commit history with diff, blame, show and so on, and get up to all sorts of other tricks. If I had to single out the everyday operations that make my life easier, these would be the ones.

• Stashing — you've started some work and need to switch branches or return the repository to a particular state without losing what you've done. That's exactly what stash lets you do. It's a stack where you can put uncommitted work and retrieve it later.
• Squashing commits — in simple terms, squash lets you combine commits into one. When I'm working on a large task with a lot of changes, I commit as I go. When I want to propagate those changes into the main development branch (master), I combine all the commits into one big commit. The history of master then reads as a clear sequence of features and bug fixes instead of a thousand and one commits. The gatekeeper, or repository maintainer, can tell what's coming into a branch we consider stable and debugged.
• Amend — lets you change the last commit. I can fix a typo in a commit message, add more files to the commit and so on.
• Cherry pick — lets you take a single commit across several branches. A classic example is a bug fix that needs to go into master as well as the branches we use to build the preproduction and production machines.

I'm sure I've missed something. One example that comes to mind is committing only part of a file. If you use Git, you may have a favorite feature you'd never give up. That depends on how you use Git, as the next paragraphs show.

Git is a good servant but a bad master

Git's biggest advantage and disadvantage is its flexibility. With SVN I was used to a routine of checkout, update and commit. Git doesn't have a single routine. There are as many ways of working as Git gives you options and as the design of your development process allows. Git certainly won't hold your hand. You can use Git just as you used SVN, but then it's worth asking why you'd switch at all if SVN isn't a problem for you in practice or in principle.

As I suggested when I talked about squashing commits, our development process makes heavy use of branches. We have a master branch (trunk), where tested changes go. I make a local branch for every task. If I need integration tests or the other conveniences of our continuous integration system, I create the branch in the central repository too. When I'm finished, I merge into master.

Note: Personally, I'd prefer separate repositories for the larger components and a gatekeeper through whom all merges into master would flow. The gatekeeper would review the code and pass the commit along if satisfied.

This example shows how many ways there really are to use Git, and it's up to you to find the one that works best for you. In the podcast we also touched on a competing distributed version control system, Mercurial. From the feedback we got, Mercurial is stricter in this respect and might make it easier to get started with distributed version control.

Tools

At first I had a lot of trouble with the poor Git support in Eclipse. Now I'm grateful for it. The trouble with tools is that they shield you from how Git works, and if you don't understand that, you'll have a problem later. I can't even imagine doing some operations from the IDE alone. This is how I learned to use Git from the command line, and I swear by it. As a bonus, I learned a little Vim alongside Git. For Mac users I'd also recommend GitX, which visualizes the state of each branch nicely.

I want to know more

• Series: Five reasons to choose Git
• Why is Git better than X?
• Pro Git (Czech edition)
• GitHub