GitHub Enterprise vs Team Foundation Server (TFS)

Question

We will start a new project in the company I'm working on. This is a software development project in C ++ and C #, with ~ 6-8 developers in three places.

In older projects, it uses SVN and a custom error tracker, but it plans to switch to TFS. For this new project, I would like to convince management to use GitHub Enterprise instead of TFS. I don't have much experience with TFS, but I used git a lot and had some experience with GitHub.

I specifically ask a question about the full experience, that is, the integration of version control, problem / bug tracking and a wiki. There are a couple of related questions here, but they focus only on the aspect of version control. So:

• What are the main benefits of GitHub Enterprise for TFS?
• What benefits does TFS offer than GitHub Enterprise cannot replicate?
• Which of the two solutions offers the best support for continuous integration?

All development will be on Windows machines using Visual Studio (2010, possibly 2012).

Answer 1

Well, I can’t give you the full answer. But we looked at TFS for Java development, and here are some points that may be of interest to you.

• we encountered length restrictions for path + file name using TFS. This seems more likely with Java, since packaging in C # is done differently.
• blocking: creating a file somehow blocks it in TFS (or reserves a "place" for it). It was very annoying when people were not in the room to fix these files. With distributed teams, I cannot imagine how this should work.
• CI with Java was dirty. It worked, but compared to Jenkings / Hudson / Bamboo / TeamCity, I would not use it for Java. Using C # may be more interesting since TFS allows you to create workflows for CI assemblies. In this way, certain assemblies can be upgraded to automatic deployment. But I never used this in real life. I just liked the idea :)
• Tracking problems in TFS is fine. Scrum / Agile planning plugins are also available.
• TFS wiki is a waste of time. But GitHub wikis are based on Git, so people need to write markup. This is normal for developers, but I have some doubts that members of our team come from this area.
• I don’t know what CI is built into GitHub? All CI servers that I know have Git support.
• Git Windows client is a bit weird. The msysgit client has path length restrictions, cygwin is one weirder (it just feels it), but both work well. GitHub has its own client - I do not know what it is based on.

Given that your team is distributed, I would go for Git. This will allow a more flexible workflow. If the network is stable, then TFS will certainly do the job. If you've worked with SVN before: TFS as a source of control will certainly help people. But the developers used for VisualStudio and MS-Server-Parts have much less conflict with it.

Again: we tried (or should have tried) using TFS + Java, and C # + Visual Studio is a completely different story. Integration there will be much better. However, some of my points may be useful :)

Answer 2

I can’t comment on TFS specifically, since my only experience with it was brief and very unpleasant, so I don’t want to.

However, I use git and github (enterprise version), and I have worked with various centralized VCS (rcs, cvs, svn, synergy) and decentralized VCSes (hg, git).

I think that the main difference between git and TFS besides some additional distinguishing feature is that TFS is based on a centralized system (e.g. rcs, cvs, svn and synergy) and that git is a decentralized system (dvcs), At first it can seem insignificant, but it has profound consequences.

• The dvcs repo clone contains the entire history, so you can continue to work, switch between branches, perform functions, etc. If the network does not work, the server does not respond, you are sitting on an airplane, etc.
• Since commits are local to your cloned repository, you have another degree of freedom (orthogonal to branches, etc.) where you can work on a function by creating a clone of the repository function, and if that doesn't work, just delete the repository. and it will never go down in the history of the upstream repository unless you clicked.
• DVCSes do not define a specific workflow. You can structure the interaction of your team in any way (multi-level, orthogonal, flat, centralized that you have). This is a great advantage that helps teams grow (and shrink) without being left with a system that cannot meet their design needs.
• GIT (and hg) supports things like patches / quilts that can be used for continuous integration. This is usually difficult to do in centralized VCS, so basically it just hasn't been done (I don't know if TFS has these features)