New Revolutionized Git is here

The movement from centralized to distributed VCS is accelerating. Enterprises and tool vendors are catching on and catching up with what open-source developers have been doing for a while. And at the front of the parade is Git.

Version control used to occupy a sleepy corner of programming technology. After Subversion replaced CVS, it became the de facto VCS system for open-source projects and in small IT organizations. Large enterprises continued doing what they always did, which was to rely on larger packages such as Rational ClearCase and Perforce to handle the massive code bases and to enforce important constraints such as access rights, partial codebase visibility, and so forth.

The world stayed in this happy steady state until the 2004-2005 timeframe, when one of the preferred VCS vendors of the open-source community, Bitkeeper, decided to withdraw its free offering. This event prompted two developers on the Linux project to create competing distributed VCS (DVCS) systems: Git and Mercurial. Both products offered similar functionality. The notable enhancement they both offered was that they blurred the concept of a central master copy, they made it easy to create forks and branches, and to do merges. In sum, both products were ideal for open-source projects. Pretty soon, communities sprang up around each one: Bitbucket became the premier host for Mercurial, GitHub the leader in the Git market.

Each DVCS had marquee projects: Git had Linux, Mercurial had Mozilla, most of Sun’s OSS, and more recently, Google’s Go. The general perception was that, while they offered similar functionality, Git was not Windows-friendly, whereas Mercurial was.

Git eventually move squarely into first place, as the result of the great popularity of GitHub, the project-hosting site that offered many free services attractive to OSS projects. It built a strong community, which BitKeeper — its Mercurial counterpart — could not match. (The GitHub-Bitkeeper competition is back in play as a result of BitKeeper now supporting Git in addition to Mercurial. BitKeeper also provides one attractive feature missing from GitHub: unlimited free private repositories.)

Even Mercurial advocates admit that Git is now the unquestioned DVCS champion. But most of them see no need to migrate from Mercurial. However, migration from pre-DVCS systems is indeed the order of the day. Our lead feature this week describes how Atlassian moved the codebase for its JIRA product from Subversion to Git. The net effect of the move was that Atlassian is able to release more often because its workflows were improved in ways that would have been very difficult to do with Subversion. The details of the specific benefits and the challenges of the migration are all spelled out in the article.

For large enterprises, Git has some limitations that need attention. And indeed traditional tool vendors are starting to provide the missing pieces. For example, Git repositories become unwieldy once they cross 1GB in size. GitHub strongly encourages customers to break up their repositories into sub-repositories to keep each one under the 1GB threshold. However, for large codebases, 1GB is a small number. To address this, Perforce has just released a Git front-end to their well-known VCS, which is distributed and routinely handles codebases in the 10s and 100s of GBs. (By the way, Perforce offers their VCS with the Git front-end free to teams of up to 20 developers.)

Managing Git is another issue for which tools are beginning to appear. For example, Atlassian just released Stash, which helps sites run Git behind the firewall. It provides management tools as well as features such as fine-grained access control. (Forking a project is fine in OSS, not so fine within the enterprise!) The latter is particularly important for outsourced work, where you want developers to access only the portion of the code they need to see for their work.

A final issue being tackled by vendors is that the DVCS model muddles the concept of the golden master, which is a primary architectural feature of the centralized VCS model. Many organizations are not comfortable with the uncertainty around this point, and so tool vendors are providing a cross-over kind of model where the concept of golden master is maintained, but the remaining benefits of the DVCS model are installed and enjoyed.

In much the same way Subversion cleared out all the old CVS-based projects, Git will do the same to Subversion. How Mercurial fares in that scenario is hard to tell. Either way, though, the DVCS revolution is here to stay.