Over the years of developing software I’ve used my fair share of version control systems. Zip files, CVS, Subversion, Perforce, and Source Safe (should I even mention it? Even Microsoft avoided it). Honestly, sometimes zips and diffs were better, and I never seemed to trust any of them completely. Something invariably went wrong or didn’t work right. I remember subversion repositories just full of issues. Branching? Can’t really do that.
As soon as I found Git I knew I would solve the majority of my problems. For the last few years I’ve been using Git as much as possible. We even use it here at Argenox developing code for boards and customers, and we couldn’t be happier. The distributed aspect of Git pays huge dividends as far as being able to work on multiple things simultaneously. Branching and adding a new feature to the firmware, testing and then merging it back to the main branch is seamless. Negotiating merges is also quite simple. Most importantly, we don’t stop. Here’s what sometimes would happen with Subversion:
A couple of us would work on code. Invariably, a commit in the subversion repository wouldn’t work right and the build would fail. We immediately stopped committing code to try and resolve the situation No server access? You continue working on the code, which means you keep building up more and more code in your local copy. When the server is finally back up you have two choices: The first is to commit everything at once, meaning that the commit isn’t atomic. The second one is to introduce the code piece by piece in multiple commits (hopefully you remember every single file and what you did). Can you remember every single change for a few days? There’s always something missing. And even if you keep notes it is a complete waste of time. With Git this doesn’t happen. Even without access to the main server, your repository is just as good as the server. You can branch, make commits, and delete them. You keep working the way you always do. When the server is back up, you can push the commits, merge and build. Life is good.
Branching is perhaps the most frequent thing programmers do, even if you don’t think of what you’ve been doing as branching. How many times have you copied the code to test out some change that maybe didn’t work out? Worse, you changed the main code and then backing up some of the changes didn’t work out that well. Even if it worked well, maybe you wanted to keep it out. Branching in Git can be used by every kind of code change or addition, and it is quick. I feel this is the way most programmers think and work naturally. There’s no need to break the pattern. Doing so creates mistakes.
For those who might not even be using any kind of version control please stop right now and take the time to learn Git. I’ve seen people avoid using Source Control completely, but only for a single person. When working in a team, or when sharing information with customers, it is important to know what you’re delivering. When a bug shows up later you can trace it down to a commit. Having a process isn’t just a good idea, sometimes it is mandated by quality control or contracts.
Some people use Mercurial, which is also distributed, but it has a few downsides. The biggest one is that branching required a new repository. The fact that the Linux Kernel itself uses Git is both reassuring (given the number of people collaborating), and almost a must. If you do any Linux Kernel work you almost have to use it to pull and merge patches and changes. As always, something is better than nothing.