Phases of Git Adoption in the Enterprise
Git, as part of the SCM/version management technological landscape, has been the subject of study here at Perforce for some years. The last year or so we’ve seen Git usage increase dramatically in large development environments, many of which are, naturally, our customers.
If you are the SCM administrator at one of these companies, you likely have heard of Git, are supporting Git successfully, or somewhere in between.
If you are a developer using Git, you might be unaware of the possibly heroic actions taken by your SCM administrator to deliver the “Git experience” you expect.
We’ve noticed a fairly consistent pattern emerge during the adoption process which you might find interesting, or perhaps it will spark a discussion about how Git adoption has worked at your company.
Curiosity - “What is it?”
Annoyance - “How do I keep it out of here.”
Requirement - “How do I deploy it?”
Pain - “How do I make it work?”
Solution - “Whew!”
Your company is aware of Git as a hot industry trend, but there’s been little or no known impact on your SCM architects or SCM deployments. You might be curious enough to check out who is using Git, thinking it is likely just a handful, and then end up surprised to find there is far more going on than first met the eye. That’s partly because the distributed nature of Git makes it easy to slip, undetected, into development organizations. Developers can use features like git-p4 and git-svn to export code to git repositories that are unknown to their corporate SCM administrators. That sets the stage for phase two.
Having discovered that developers are making widespread and/or growing use of Git, the SCM administrator may start to worry about where the company’s IP is traveling, if developers are subverting business processes, or that they might end up having to support this tool. They may try to stamp out Git use, or put controls on it. The developers, on the other hand, are enjoying the benefits from true versioning in the workspace, subverting restrictive business processes, and using a cool, trendy tool. The resulting conflict sets the stage for creative innovation.
The third stage is when the organization decides supporting Git needs to be an official requirement. Sometimes the decision comes from a CTO or upper management reacting to industry trends. In other cases Git evangelist developers get official buy-in from management. A next step might be to start an initiative to “enterprise harden Git”, or build or buy a repository hosting solution.
Here’s where the fun starts: Git faces special challenges at enterprise software development scale that are not trivial to overcome. I’ve written about a few in my article “Git Puzzles: Missing Pieces to Git in the Enterprise”.
The result is that Git developers at these companies are facing erosion of the fast and flexible Git experience they’ve come to love. Multi-hour clone times, common commands that are too slow or unusable, and poor multi-site support all contribute to chip away at the promise of fast, responsive distributed version control systems.
Although we know of many companies working on a solution, the list of successful, global, and vertically scaled deployments of enterprise Git is a short one. In fact, as of this writing, we don’t yet know of one, and would love to hear about it if you do.
Git Fusion is Perforce’s approach. We take a slightly different tack at the problem than most by concentrating on freeing the files from the obstructionist clutches of the repositories. We hope the result is bringing the goodness of the “Git experience” to thousands of enterprise developers, maybe even you!
If this looks promising, or even if it doesn’t, we want to hear your feedback and thoughts!