GitHub Enterprise vs. Team Foundation Server (TFS) [closed]

Question

We will be starting a new project at the company I'm working at. It's a software development project in C++ and C#, with ~6-8 developers at three locations.

Older projects here use SVN and a custom Issue tracker, but it's planned to switch to TFS. For this new project, I would like to convince the management to use GitHub Enterprise instead of TFS. I don't have too much experience with TFS, but I've used git a lot, and have some GitHub experience.

I am specifically asking about the complete experience, that is, the integration of Version Control, Issue/Bug tracking and a Wiki. There are some related questions on here, but they focus on the version control aspect only. So:

• What are the main advantages of GitHub Enterprise over TFS?
• What benefits does TFS offer than GitHub Enterprise cannot replicate?
• Which of the two solutions offers better support for Continuous Integration?

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

Answer 1

Well I can't give you a complete answer. But we had a look at TFS for Java development and here are some points that may be interesting for you as well.

• we encountered length restrictions for path+filename using TFS. This seems more likely with Java as the packaging in C# is done differently
• locking: creating a file somehow locks it in TFS (or reserves a "spot" for it). This got quite annoying when people were not in the room to fix these files. With distributed teams I can't imagine how that is supposed to work.
• CI with Java was messy. 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 workflows for CI builds. So certain builds could be promoted to automatic deployment. But I never used that in real-life. I just liked the idea :)
• The issue tracking in TFS is ok. There are some Scrum/Agile planning plugins available too
• the TFS wiki is a waste of time. But the GitHub wiki is based on Git so people need to write markup. That is ok for developers but I have some doubts our team members come from that area.
• I'm not aware GitHub has any CI built in? All CI servers I know have Git support.
• the Git Windows client is a bit weird. The msysgit client has path length restrictions, the cygwin one os even more strange (just of it feels) but both work nicely. GitHub has an own client - I don't know what it is based on.

Considering your team is distributed I would go for Git. It will allow a more flexible workflow. If the network is stable TFS will certainly do the job as well. If you worked with SVN before: TFS as source control will most certainly piss people off. But developers used to VisualStudio and the MS-Server-Parts have far less conflicts with it.

Again: we tried (or had to try) using TFS + Java, with C# + Visual Studio it's a complete different story. The integration will be much better there. Yet some of my points may still be useful :)

Answer 2

I can't comment on TFS specifically as my only experience with it was brief and very unpleasant so I wont.

I do however use git and github (the enterprise version as well) regularly and I've worked with a variety of centralized VCSes (rcs, cvs, svn, synergy) and decentralized VCSes (hg, git).

I think the main difference between GIT and TFS apart from some auxiliary feature difference is that fundamentally TFS is a centralized system (like rcs, cvs, svn and synergy) and that git is a decentralized system (dvcs). This may not seem that much of a differentiation at first, but it has profound implications.

• A clone of a dvcs repo contains the entire history so you can keep working, switching branches, commiting features etc. if the network is down, the server isn't responding, you're sitting in an airplane etc.
• Since commits are local to your cloned repository, you have one additional degree of freedom (orthogonal to branches etc.) where you can work on a feature by making a feature clone of the repository and if doesn't work out, just delete the repository and it will never have made it into the history of the upstream repository if you didn't push.
• DVCSes do not dictate a particular workflow. You are free to structure your team interaction any way you want (tiered, orthogonal, flat, centralized, what have you). This is a big advantage that helps teams grow (and shrink) without being left with a system that cannot fulfill their needs by design.
• GIT (and hg as well) supports things like patchsets/quilts directly, which can be used for continous integration. This is usually difficult to do in centralized VCSes so it's mostly just not done (I don't know if TFS has those features)