Using git (or some other VCS) at your company

Question

Some friends of mine and I were talking recently about version control, and how they were using VSS at their jobs, and were probably going to be moving off of that soon. One of them said that his company will likely be going with Team Foundation Server.

Eventually, the conversation did get around to talking about some of the open source VCSes out there, including git and SVN. None of us really knew about any companies that use either of these internally, although we imagined that a number of them did so for SVN, but we weren't too sure about git. I brought up Google and Android using it, but my friend figured that's only for the public facing source code, and that they may use something different for internal projects.

Apparently it's more than just SCM that makes TFS so intriguing:

1. Microsoft Sales people and support (although my friend did point out somethings to his managers that he thought might be misleading on MS' part)
2. Integration of things beyond SCM, including project management (I'm just finding out that there are geared towards the same things for git)
3. Again, it's Microsoft, and the transition from VSS to TFS seems logical (or does it?)

I'm not much of a fan of SVN, so I didn't really bring it up much, but I am curious about whether or not git is used at your company for internal projects.

Have you thought about it, and decided against it? Any reason why?

Answer 1

The question should be a community wiki, and is subjective.

It seems to me this is all about integration. TFS is more than just straight version control, and is integrated well? into the MS stack. If you are an MS house then it is a logical choice.

open-source philosophy denotes a 'filter' or 're-usable, small components' approach to designing systems ... and systems of systems ... if you wanted to replace TFS or some other solution, then you would need to integrate SVN, git or any other VCS into your solution.

MS stuff works out of the box for an MS range of products. With open source, you have choice ... but you may well need to integrate it into other things (like bugzilla) to get a comparable solution. The choice is good; but it depends if your company is in the business of developing software for customers or spending time and money rolling in-house solutions.

Answer 2

Basically, when storing important code into repository, an enterprise will consider one point in particular:

What kind of support can it expect from the company behind the VCS used, when the repository crashed, becomes corrupted in any way or need to be analyzed?
Is there a SLA (Service Level Agreement) which comes with it.

You will rarely have that with open-source product, and you do not always need it (since you have access to pretty much all the -- open-source- product)

And there are other aspects to consider as well, before even coming to the "integration with other tools" part:

• administration costs
• backup costs (must the repository be locked or down to be backed up in a coherent state?)
• speed and general performances of common task
• learning curve of the product
• etc...

All of those points can influence the decision in favor of a commercial or an open-source solution.

---

Edit: just for information, I just found this these on CM (Configuration management, pdf file) which has some good arguments for or against a commercial tool. (7.4 General discussion, pages 98-99)

The reasons for choosing one of the commercial tools instead of the free-ware are many.

The strongest argument for doing this is the guarantee of getting secure, established and stable software to work with.

When choosing a freeware tool the risk is taken that bugs and other more serious flaws can be found in the application.
For example a repository created by an earlier version might not be supported by a newer release. This will very fast become a problem since free-ware programs a constantly updated and newer releases are made public very often.
The free-ware applications also rely on the users to report bugs in the application and since it is free of charge, there are no obligations towards the users from the company developing the free-ware tools.

Implementing a freeware tool would create a lot of work and a lot of time would be spent keeping track of the latest releases, bug-fixes and on upgrading the application.

The complete opposite can be said about the commercial tools.
They require few or no updates compared to the freeware applications and they will in a more effective way facilitate the developers’ work.
Even though the commercial software cost money, the man-hours you can save by using such a tool will compensate and provide you with a payback time relative to the buy-in price of the product.

Note: the above is not an "absolute" truth, and some counter-example might be found, but I believe the general argument has its merit and I add it here for others to see.

Answer 3

I don't think the development philosophy of git and DVCS in general is appealing to larger companies - a central repository makes much more sense to them (and may in fact actually work better for centralized organizations).

I work for a large IT service company in the banking sector; they migrated from CVS to SVN only 2 years ago, taking the obvious upgrade path.

Answer 4

As a consultant I've worked at several clients (some rather large names like Baker Hughes) that use Subversion as their source control system (note some teams were on TFS). I even used it at a previous employer (switched from VSS to SVN).

As far as Git goes, I have not seen too many companies using it internally yet and I doubt you will until there are better Windows interfaces for it. I have heard that things like Git Extensions and TortoiseGit are getting a lot better and I have heard of people having great success with those tools but they weren't using them at a large company.

Answer 5

We use git for all of our source code. It just makes sense.

• It's quite nearly impossible for us to lose anything since at the point where two people touch a project, we have three complete copies of it (and our backups of those repos).
• We do not rely on any centralized infrastructure -- including network. I've worked on projects in BART tunnels.

In theory these commercial systems should save you from broken repositories and all kinds of wonderful things with their support.

In practice I've lost more code and time to centralized repositories than distributed.

Answer 6

Here's my data point: In the last decade, I have worked with companies that used

• no VCS
• VSS
• CVS
• SVN
• git

roughly in that order. Some companies used several of these over the years (I have suggested and performed some of the transitions), the one company that switched from SVN to git did so when I was leaving, first using it for a library they released as Open Source.