Thoughts about using Git for closed source projects

Git is getting a lot of press in the open source world lately, but hasn’t got much traction in the closed source corporate development world. There’s a reason for this, and it’s more than conservatism on the part of the corporate developers. Git (or any DVCS, really) embodies a development culture that isn’t very enterprise-y.

This is something that I’ve noticed when talking to some of my developer friends who are working on closed source projects, in software companies or in teams building in-house custom applications. Big companies like central control, hierarchy, policies, and audit trails, and centralized software version control systems fit this very well. You get one big server in the sky that has all the source code, central control over permissions, a log of changes, and usually a way to add pre and post commit hooks to integrate the VCS repo with related systems.

With a DVCS, everybody can be a lone ranger, unless you build a process on top that puts back these features (i.e. a remote repository that everybody pushes to). This is something that many of the introductory documents I’ve seen regarding Git try to downplay — you don’t need a central repository, yippee! Just pass changes around from developer to developer — but while that may thrill the solo coder hacking on his laptop on a long flight, it isn’t music to the ears of a CIO.

In Git’s case, there is no central list of version numbers, and the history can be altered using git-rebase and git-commit --amend. Do you really need to see the precise history of every change ever made to the code? Perhaps you think you do because it gets screwed up so easily in some version control tools, and you need to at least be able to backtrack and manually unsnarl a really big screw-up. In that case, you probably don’t need it, as long as the version control tool can be trusted.

Or maybe you’re guarding against human error, and what you really want is granular remote backups. Just as you can use svnadmin dump and svnadmin load to intentionally truncate the history that the repository knows about, you could use git rebase to squash a bunch of commits together into a single big change, and thereby lose the ability to go back to one of those intermediate steps. So you probably should think about archiving the full-granularity repository before you consolidate the old historical steps for developer convenience reasons. And even if you’re a lone ranger, you should think about using rsync or duplicity to regularly put your local .git repositories someplace safe, or push to a remote git repository that no one else has access to, or both.

One solution to make Git more enterprise-friendly git-svn, which gives you the tool integration and centralness of Subversion, with the local branch/merge and offline commit benefits of Git (which are very very nice). I haven’t used it but I am told that it works very well. It’s also a very low-risk way to try out Git, since you can just check your changes in and go back to using Subversion at any time.

Git is challenging to learn, partly because the command language is not very intuitive, and partly because the folks documenting it so far are obsessed with explaining how radically new and different it is rather than how you probably will want to use it. And for folks reading this documentation, the “look how different your process could be” examples are not necessarily very appealing, since the benefits gained by using a centralized VCS are not addressed.

Still, I think Git has enough hype around it that in a year or two there will be some very slick, usable tools that conceal the complex inner workings that you currently have to understand well in order to be productive. They may also include features that make backups or the setup and shared use of a remote repository easy. So if you’re not convinced that it’s time to migrate Git now, just wait. It will probably come to where you are eventually.