Git Versus Subversion: A Reconsideration
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on April 9, 2010 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
Back in January, I wrote about my feelings that Subversion still beats Git when it comes to the corporate environment. I pointed out that Git has some great features, but that the corporate world was heavily invested in Subversion, and was likely to stay that way.
I subsequently got flamed.
Two months later, after using Git to contribute to several projects, I believe a reconsideration is in order. In terms of comparing Git to Subversion, Git is a superior technology for development. Git’s strengths lie in the fact that it’s been intentionally designed for things like branching and tagging; with Subversion, tags and branches are components of the file system rather than baked into the system. Git also focuses on snapshots of the repository at given times, rather than change sets. This difference in model makes Git faster, the repository smaller, and the merging of changes easier. In fact, unless there are explicit conflicts it’s unlikely that Git will experience any problems merging at all.
The distributed nature of Git makes it easy for project leaders to solicit contributions. Github in particular makes this process seamless: contributors can clone the repository, make their changes independent the main source control line, and then request that the owners of the project pull in their changes. Rather than having a few people that can take patches and turn them into commits, anyone becomes a possible contributor. The branches and work completed by the contributor doesn’t muddy the project history until it’s time to incorporate those changes, and the project owners need not grant write access to the central repository to anyone other than themselves.
So have I changed my mind about whether or not Git will beat out Subversion in the corporate world? At the moment, no. Despite Git’s great advances, and superior technology, Subversion is still the preference for many organizations. They’ve invested time, energy, and effort into setting up repositories, learning how to control access, integrating their issue trackers with revision numbers, and creating policies and procedures. Simply put, I don’t think that Git has enough of a benefit to override the internal momentum in favor of Subversion. Yet, anyway.
As new projects develop, I believe we’ll see more and more of a movement towards Git and distributed source control systems like it. For all the push right now towards Git, it’s easy to forget that Subversion as a versioning system still functions. It’s not a dead project, and it’s getting better (e.g. you haven’t needed to specify revision numbers during merging since 1.5). With tools like git+svn, developers will find their own solutions to using their favorite version control systems, and since the beauty of Git is in how it advances our own workflows, it’s irrelevant, really, where the data is ultimately stored. As more developers begin to use and learn Git (or other distributed systems), the momentum will begin to shift, as those developers become the leadership in various companies and projects, and push for the use of tools that they prefer, and the workflow they find easiest to use.
Technology will continue to mature. Who ultimately wins out and who falls by the wayside still has yet to be determined. But whoever the victor is, the important thing is that it make working easy and versioning painless – something we can all agree on that we need.