git: This Year's Version Control Fashion
by Mike Gunderloy - Mar. 21, 2008Comments (8)- Related Blog Posts
- SourceForge Commits to Git, Bazaar and Mercurial Support
- Using Git With Mac OS X: 6 Good Tools for Getting Going
- Sun Launches New Site for Hosting Open Source Projects
- Don't Count Subversion Out Yet
- Visualizing Repositories
Version control systems seem to run in waves in the open source world. For many years, the venerable CVS had the lion's share of usage. Then along came Subversion, with the announced goal of being "a compelling replacement for CVS." Subversion has gained enough popularity to be the baked-in choice in many tracking and management tools. Lately, though, I've been seeing more and more interest in git - the system used to track changes to the Linux kernel itself, among many other things.
If you've never used a distributed version control system before, it might take a bit for you to get comfortable with the concepts behind git. One of the chief differences you'll find between git and systems such as CVS and Subversion is that with git there isn't some master repository of everything that you copy in bits and pieces to your local computer. Instead, your local working copy contains the entire history of the project, and any two copies can exchange patches. It's possible to set git up with a central "master" repository that everyone uses, but that's more of a social convention than a software requirement.
Coupled with this distributed bias, git makes branching and merging almost trivially simple. It takes two commands (most users run git from a shell, though there are graphical front ends available) to create and switch development to a new branch - and even with thousands of files in your repository, it's a fast operation. This makes branching a much more viable strategy for day-to-day development. Even with Subversion, the overhead of branching and merging used to keep me on the main line of development more than I should have been. With git, I can branch even to fix one or two bugs - and even when other developers on the same project are doing their own local branching, we find merges to be fast and easy.
Git is also designed to coexist fairly well with other version control systems. For example, if you're working with a project where everyone else is using a master repository and Subversion, you can simply put your own local working copy into a git repository of your own, and use git commands until you're ready to check back in to the master. There are also import and export hooks to move repositories from Subversion (as well as other popular systems).
The biggest challenge in git, in fact, is not using the system but learning how best to use it. If you're coming from a Subversion background, it's worth reading the git-SVN Crash Course. You'll also find plenty of other documentation on the main git site. If you learn better by seeing than by reading, take a look at the Git Screencast from Peepcode.
The choice of a version control system is driven by many things: features, politics, and personal preference as well as fashion. If you haven't used git on an open source project yet, it's definitely worth kicking the tires. You may discover it's worth switching from your current system.
What version control system do you use?Â
