I was recently using a commercial centrally controlled version control system in a large company with about 100 different subsystems written in different operating systems and languages, and I have noticed that several developers use either git or mercurial on their pet projects, but not for their work systems. I personally am more familiar with git but was wondering what reasons are their to "Not" use Git in the enterprise, apart from the fact that the choice has already been made (we have many problems with our centrally controlled version system, so I can't say it is brilliant).

Update

The wor开发者_高级运维ld has indeed changed since I wrote this. The company in question that actually disallowed Git at the time now uses Mercurial as their preferred system

I have to disagree with the ideas that Enterprises are afraid of free or that they are slow to change. These may be true but to use them to dismiss the slow adoption rate of git in the Enterprise space misses the point of what Enterprise means. Besides, SVN is pretty popular and it's free.

Enterprise is about centralization. You want all your developers to follow the same procedure, get the same code, etc.

Eric Sink is more eloquent on this subject than I could be: http://www.ericsink.com/articles/vcs_trends.html

If I had to guess, I'd say it's because enterprise has always been wary about using "free" things. Mostly because they lack a stable support system (generally, support comes in the form of StackOverflow.com or forums when it comes to open-source), but there's also a pervasive mentality of "you get what you pay for." They figure if it doesn't cost them a buttload in licensing fees, it must be worth as much in terms of real usability.

Of course, we, as tech experts, know that's a load.

In my experience, Enterprises have a lot of anti-bodies against change

Existing skill-sets: if large part of the team has skills on existing tools, they will automatically become an obstacle of changing them, even for better ones.
Consolidated stability: change is always a pain in terms of migration and stability. What is in production "works by nature" and every change always create problems.
Compliance: existing tools have been analysed and validated by Enterprise ICT Security and then defined as "standard and compliant" with company procedures. Anything different will be seen as a potential security risk.

IMHO then the problem is not GIT itself or a Distributed Version Control: the problem is changing the SCM and going toward something unknown and potentially "dangerous" for the Enterprise ruleset. That's why the "antibodies" comes into play to prevent any significant change.

More specifically on GIT, many risks and threats are providing additional arguments against its adoption, related to the three points mentioned above:

Skills-set: GIT is different from any other SCM used so far. Naming is ambiguous and misleading (the "svn checkout" is a "git clone" ... whilst a "git commit" is not a "svn commit")
Consolidated stability: GIT has been very unstable till Ver. 1.6. We have used it on Windows since Ver. 1.5 and it has been a real pain, particularly with unexperienced devs.
Compliance: GIT has no identity enforcement by default and doesn't provide a clear trace of who did what. It is "peer-to-peer" so by nature is against central control and auditing.

I have seen the "anti-bodies" in action many times before GIT:

1996: migration from RCS to CVS
2001: migration from SourceSafe to CVS
2005: migration from CVS to Subversion
2009: migration from Subversion to Git

In all those examples has been key to highlight the plus and minus of the change in an Enterprise-wide terms: evaluating risks, costs and benefits ... and all with clearly in mind who are the anti-bodies and how can we mitigate them or "assure a nice alley for them to walk with old tools".

After a lot of pain and effort, all those migrations were eventually very successful ! I have introduced GIT in large enterprises such as Vodafone Group Services in the UK and Germany. After pain and resistance anyway, the change has taken off and benefits are visible and have already provided a significant ROI in terms of efficiency, agility and control.

On the compliance and support side, I have seen helping positively the adoption of Vendor-assisted sponsorship. Some examples:

CollabNet (http://www.collab.net) for SubVersion adoption with RBAC Security
GitEnterprise (http://www.gitenterprise.com) for Git Enterprise compliance with SOX and CMMI
Google (http://code.google.com/p/gerrit/) for Gerrit Code Review introduction and change tracking

Generally speaking, change is the most expensive but MORE IMPORTANT task in a large Enterprise, first of all from the point of view of people mindset.

Let me know what you think about Git and Enterprise Tools adoptions !

Luca / @lucamilanesio

Some of the many reasons:

Inertia: There's an enormous number of people out there familiar with centralized systems. You don't have to "retrain" developers if you just don't change.
Interactions with other tools: Corporate environments are of course big on extra tools like continuous integration, IDEs, fancy issue trackers, and so on. Naturally, there's more support for the established centralized VCSs with those than with the relatively new git and hg.
Support: When you buy a commercial VCS product, you're not just buying the program, you're buying peace of mind.

Of course, I'm not saying these are good reasons; they're just convincing to people in the position to make this decision. I think it's worth overcoming inertia - it takes work now, but it pays off later. I think the external tools are getting better at supporting git, particularly the open-source ones - they just need plugins. And as for support, we all know there's plenty of less formal support out there on the internet.

Really, there's a common thought in all of these - the free software philosophy just isn't the way corporations do business. Buying a product is established and easy. You pay your money, you get what you need. Management doesn't have to worry. Using a free software product... well, it may be much better, but it's more complex to deal with. It doesn't come in a box.

A clarification: I use the word "free" in the same way those in the free software world do - free as in freedom not as in beer. Hopefully this phrase will get drilled into everyone's heads eventually. Note that I never dealt with the issue of cost here - though I do think that in the case of git, in general it will be ultimately be cheaper than a purchased solution despite the costs of bringing everyone up to speed on it and making sure it fits in with the rest of your process. This isn't a cut-and-dry issue though, and since I think git comes out ahead, there's no sense putting it among the bullets.

From my experience it is the fear of change. Source code management is a central piece of infrastructure and affects all developers. If the current system doen't hurt too much enterprise IT will actually fight change.

Another reason I've heard quite often is that IDE integration has not yet reached the quality of e.g. CVS or Subversion. Though the argument is true it is becoming increasingly lees an issue.

This same question can be asked about switching any large infrastructure service with something else. When there are hundreds or thousands of people using something, it had better be broken or the new thing had better offer some compelling features.

Think about switching email systems. Someone is going to have to train all the users, transfer all of the messages, make the switch with minimal downtime and without losing data, and then convince management it isn't going to cause a major disruption to business operations.

In your specific example, converting the source control system for 100 subsystems while retaining history and retraining all of the developers, testers and release engineers, and not impacting their daily productivity, is a huge task. The existing system will have to be really broken.

Git is a version control system with an attitude of collaboration and sharing. There is practically no way you can enforce a specific pattern of access and sharing. If the people who're using git don't want to follow your rules, the tool is not going to help you much.

Although I personally think this kind of organizational behaviour is stupid, I'm sure somewhere someone thinks it's a good idea. Maybe you're concerned that your unruly employees work on the wrong projects, or you're desperate to keep changes out of the code.

"Apart from the fact that the choice has already been made"

That part of the statement is actually too important to disregard, because it ties in with the learning curve of any particular tool. Learning, for example, SVN takes a while, and the learning process costs money in the form of developer time. Learning git, in my experience, takes more time, and is made more complex in the absence of simplified interfaces (gittortoise's ongoing development not withstanding). Plus Git has so many tools that it's learning curve could actually be considered more of a learning slope.

The payoff after getting over the curve is great, but the initial requirement is a barrier to adoption.

A significant practical barrier to enterprise adoption, apart from lack of central control and integration as mentioned by Eric, is "ease of use".

If you are used to Subversion, or similar tools such as PVCS, then Git (and DVCS in general) represents a significant learning hill to climb -- both at the conceptual level and the daily workflow. In my (somewhat jaded) experience many enterprise developers are often unwilling to invest the effort in learning a new tool or concepts; and I fear will scupper any attempt to introduce DVCS.

Please prove me wrong

Here are some specific recommendations. (read the full blog here).

If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But you can’t do anything else with Subversion (slip-ups or no), and “compelling requirements” like Sarbanes-Oxley are happier with guarantees than possibilities.

If you plan to maintain parallel, largely shared but permanently somewhat different lines of the same product, use Git. One common example: perhaps you have a large product that you customize for each customer. The customizations are permanent, and generally not shared among code lines, but most of the code is common to all. Git was designed for just this case (in Git terms, local customizations to the common core, and occasional feature or bug-fix contributions back up-tree).

Neither of those? Take your pick, you should be fine with either tool.

Part of the difficulty is not due to the sytem but to the organisation of the workers.

SVN is easy to understand and use but better if used for few dev working on a single branch (or head)

Git is a good idea but the implementation is very disgusting and it takes A LOT of time and work to do something as simple as putting your damn code in !

we still wait for a DECENT DVCS ...