This is a template email I’ve saved for when anyone bales me up in the elevator at work, asking why we’re not using Git:
I get asked this a lot. Almost weekly.
First of all, I think Git is great, it really shifts teams away from the single node distributed development model used by CVS and Subversion and opens up a world of possibilities for feature branching, release branching, mixed stream development and various other source code gymnastics that teams might need to perform. I personally use it at home. It makes Subversion look like “the dark ages” (yes, someone has actually said that to me with a straight face).
However, at |company name|, we will not be migrating to Git in any foreseeable future plan; I would not expect Git to be in mainstream |company name| usage for at about 10 years. For a company that is just phasing out IE6, this would be like the Wright Brothers planning a lunar mission.
“Why?” I hear you ask. “It’s awesome. It gives us so much more flexibility!”, “…it’s more powerful”, “..it’s more reliable”, “..it’s faster”.
Some of the hyperbole people use to describe Git is completely true, and some is just outrageous hype. 10 years ago I remember exactly the same comments about Subversion. “How can I possibly survive without atomic commits?” they said. This is usually uttered by those who want to bang every nail with any shiny new hammer they can get their hands on; resume driven developers.
Yes, Subversion gave us some important improvements over CVS; directory movements and history by far the most important. But when it was new it also brought a whole heap of trouble. The tools were very poor. They were unreliable and at times quite dangerous. I’ve lost a few local changes over the years. But now it’s mostly stable. The tool support now is good, 1.7 seems to be a pretty well supported format. Not perfect, but good enough for my precious source code. And the transition from CVS to Subversion is pain free. The model is the same: single node, distributed. Nothing too hard to get your head around.
On the other hand Git is not easy to get your head around. In inexperienced and undisciplined hands it has the possibility to become a vastly complicated network of source code branches and sub-branches and sub-sub-branches. The tools are flatout terrible, hard to use and poorly documented. Is this “bad”? – no absolutely not, it’s exactly where Subversion was 10 years ago.
But at the moment, it’s bad for us.
We’re a bank. In a large organisation we rely on a variety of people at different skill levels to perform tasks using source control for really, really important reasons. These people are of mixed capability, some would be fine dealing with Git, most would not without significant investment in training and safety “process”; And there’s nothing we can do about the tools, it would only make the safety measures more critical. When you run software teams for a large number of different platforms and business goals (and I mean large), standardisation is important, allowing for the transfer of skills, ease of administration, support etc.
Subversion is currently the bank standard for non-mainframe application source control. There are critical audit remediation programs across the bank to move applications to source control (not just to Subversion, but to source control). There are other audit programs to move application source control to the banks supported Subversion service.
“moving to git” for one tiny, relatively insignificant application within |company name|, would be contrary to trying to achieve standardisation; contravening audits, not to mention the capability issues already mentioned.
“moving to git” is a much more problematic proposition than just how you check out your