A discussion amongst some colleagues emerged recently how in today's software industry, two separate worlds exist:
How much is Git used in corporate environments?
What is your experience with Git in a corporate environment?
On
I don't think it's an opinion that matters, but facts. Also, closed source companies do not usually like to reveal the details of their internal architecture. So... I don't think there is a complete and correct answer to this question.
On
I don't know, but we use Microsoft Visual Source Safe 6.0. They are looking into buying the new version. When I proposed git or svn, they hand-waved telling me that they were free (as in beer), therefore bad.
I can expect corporations to use any POS that there is around and cost money ever since.
On
Disclaimer: the above post is just my humble opinion, I do not know how decisions are made.
I suspect that the force behind not moving to git is not "free is evil" but huge migration costs. Should a big corporation try to migrate to another system ir risks breaking something.
Monetary return of moving to better system should be predicted and compared with direct (easy to calculate) and indirect (temporary productivity loss, breaking build progress, integration with bug tracking system...) costs. Since no-one knows to calculate the indirect costs decision makers may prefer to assume that the costs are huge.
On
Came across this while looking for a way to use Git at my workplace. Sorry to disappoint but I am not "against" free software, it just that Git will not work for us without help. You might have some insight into Git's short coming if you tried to understand before calling names.
On
For newly established companies or companies that have never used version control before, there is no migration cost to git.
And for novice developers, git is more suitable because the senior developers/manager can guide them to "manipulate" better revision history before pushing to central server. Tell them to git commit --amend if they find anything wrong in the history.
If CVCS is used, chaos may happen when multiple users committed their code. There is nowhere to practise how to produce a good commit.
The only concern is the revision number, if you need that number as product version number. Because git use hash. You may need git describe or other method as a workaround.
For what it's worth, we use git in my workplace. Everyone is quite happy with it. Of course, no single person is really going to be able to tell you how common it is.
I suspect the continued prevalence of cvs/svn is much more to do with inertia than anything else. They were definitely among the best (if not the best) choices for a long time**, and a large number of developers have had the chance to learn to use them well. If most of your workforce is already comfortable with them, and they're good enough, how many companies can we really expect to try something new?
Another common factor in corporations' decisions has to do with a sort of stigma attached to free software. People tend to associate monetary cost and value, perceiving more expensive products as better (For example, I've read about a psychology study where people were given the same wine twice, and told one was a more expensive variety. They tended to rate it as tasting better). With software, there is a certain amount truth to this attitude - you can often buy some guarantee of support and maintenance with a product. We all know established open-source projects can easily still win out (more testers, more documentation writers, faster bugfix releases...), but I'm sure this still motivates many companies to purchase VCS/SCM products. However, this is clearly not the reason people are using cvs/svn.
** Please, no flamewars! I'm a diehard git fan, but I know it hasn't always existed. Of course, some still disagree, like Linus Torvalds: