About a week ago, I started taking a look at a new version control system (at least it’s new to me). The version control system is called Git, and it’s one of a new generation of distributed version control systems that are being targeted towards geographically distributed teams. Git is gaining significant ground in the open source world as it was originated by the Linux kernel team to coordinate their development of the Linux kernel. But I’m seeing it pop up on more things such as FitNesse.
What’s the difference between Git and other version control systems such as Subversion or Microsoft’s TFS? First, Subversion and Microsoft require a centralized server where developers will check out a copy of the source code and will check their changes back into the server. For all intents and purposes, the developers cannot effectively work offline without access to the server. Once changes are made, the developer needs to be connected to Subversion or TFS in order to commit their changes back to the repository.
Git works a little differently. Like Subversion and TFS, Git also requires a central storage location for teams to connect to in order to share their changes. This could be either a Git service or a file share. But instead of requiring developers to be connected to the repository in order to work, Git instead has developers clone a repository, thereby creating an exact copy of the repository on their computers. Once the repository is cloned, the developer can work in the project and perform actions such as committing changes, creating branches, and tagging revisions all within the local repository. If the developer is part of a team, other developers can clone his repository and also work locally.
When a developer gets to a point where he needs to share his changes back with the rest of the team, the developer can merge his local repository with the shared repository. All of the commits, branches, and tags get moved up and merged into the shared repository, and will be shared with other developers when they clone or update their repositories from the shared repository.
I’ve been reading up quite a bit about Git and looking at the source code. While I don’t understand all of its internals yet, I do have to say that I am impressed with its model and how it works compared to other version control systems such as Subversion and TFS. I use Subversion at my home for my personal projects, and I use TFS quite often for CodePlex and the commercial projects that I work on, so I’m very used to the models employed by both of those systems.
While I really like about Git, however, is the isolation that it provides from other developers, and the productivity boost that it seems to provide. What seems very nice is that developers have the ability to create their own branches to go exploring within their own repository, and other developers don’t have to be aware of it. For example, in my current TFS environment, it would be nice to be able to create a branch to play with refactorings that I’m thinking about, but if I create a branch in TFS I have everyone questioning what I’m doing and why.
The offline capabilities of Git are also a great feature that I sorely miss with Subversion and TFS. I can’t really work on my projects when I’m not connected to the servers, because I can’t commit changes. If I reach a check-in point while working offline, I’m stuck and really can’t proceed farther because I might break something and I can’t undo my changes. By having a local copy of the Git repository that I’m always working with, it’s not an issue anymore because I can commit whenever I want to.
The only shortcoming that I see right now on Git is that it’s not really ready for “prime time” on Windows, but Subversion was at the same point. Hopefully, Git will continue to gain speed and will someday have an integration with Microsoft Visual Studio. Maybe even I should step up and start working on something to help make Git’s adoption on Windows go much faster.