8

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).

Community
  • 1
  • 1
Wilbert
  • 7,251
  • 6
  • 51
  • 91
  • I too, am asking this question right now. I'm especially interested in the Visual Studio development experience, automated testing, and continuous deployment possibilities. Don't forget that the official GitHub client (or SmartGit) makes Git on Windows much more friendly. And things like posh-git (for PowerShell) are just awesome. – Eric Falsken Oct 08 '12 at 19:42
  • Team Foundation Service (http://tfs.visualstudio.com) and Team Foundation Server 2013 now allow you to host multiple Git repositories and traditional version control repositories (if you choose) inside of the TFS instance. Choose hosted or on-premises editions based on which direction you want as well. Having Git now part of TFS allows you all of the other benefits of TFS but with an Enterprise-grade true implementation of Git. Check out more details here: http://blogs.msdn.com/b/bharry/archive/2013/06/19/enterprise-grade-git.aspx – Ed Blankenship Aug 05 '13 at 05:33
  • @EdBlankenship, re: "Enterprise-grade true implementation of Git", you're talking about Github Enterprise, right? – Justin Mar 22 '16 at 02:07
  • @Justin - I was not referring to GitHub Enterprise (a competing product). The way we store files on the backend in Git repositories in Visual Studio Team Services/Team Foundation Server, is done in a way that enterprises would want to make sure their data is secure, available, backed up, etc. without having to think about it much more. – Ed Blankenship Apr 03 '16 at 02:17
  • well, it's now 2016 and am I am using Git on a project by night and TFS 2015 by day. I have just wasted 2 hrs screwing around with Git. Git is complicated and frustrating to me. Commit's fail, then I have to rebase the whole thing, but it happens so infrequently, I have to figure out how. Even when I figure it out, the procedure may or may not work. For me it comes down to trust of the VCS - My Git source is probably screwed somewhere, but I know my TFS is steady and stable. I never thought I would see a VCS worse than Serena Dimensions - but Git is. – jlo-gmail May 19 '16 at 03:10
  • @jlo-gmail We've been using GitHub:Enterprise for 4 years now. While I do agree that Git does have a steep initial learning curve, we now have a process and workflow that just so much more efficient than what TFS can allow us. Personal forks + ci builds, cheap branching, ... - I cannot imagine ever going back to something like TFS or subversion. And our developers are in love with git too, they even want us to move all our legacy projects to GitHub (even if they only need to work on them for a few days/year). So I can only say... climb the learning curve, and you will see the benefits too... – Wilbert May 19 '16 at 09:29
  • Beware of confirmation bias - the tendency to find reasons to agree with your position(See Scott Adam's blog). A vcs should not have a "learning curve". It should be simple to use and foolproof - otherwise it's a waste of time and a danger to a project. I have been using Git for 9 months now - how much learning curve does it need ? CI is embarrassingly easy in TFS and Branching is easy as well. Merging is automatic - if you trust the merged branch won't break something. TFS even offers "gated builds" for large teams working on large projects. – jlo-gmail May 21 '16 at 04:00
  • @jlo-gmail Applies to you as well :). The whole benefit of using GitHub instead of TFS is that you _dont have to trust_ for branching & for CI, you have personal hubs with no interference but the ability to share, etc. Gated builds and even feature branches are a thing of the past once you change the process and not just the tool. You can use git for years and still use a old-style branching mental model, not use personal forks, etc. Just because it works doesn't mean you're at the top of the learning curve ;) – Wilbert May 23 '16 at 08:49
  • At some point you have to merge your "personal hub" into the main branch to release a product. At that point, you need to trust or not trust the automatic merging process. My issue is the seeming "never ending" git learning curve. I have spent more time on git's idiosyncrasies, than I can count. And what happens when a past local commit is not compatible with the main line ? – jlo-gmail May 23 '16 at 18:29
  • @jlo-gmail I am sorry, but that statement exactly shows that you are not on top of the learning curve yet... No, you don't need to trust the automatic merging process. You locally rebase on master and then make a pull request, and the CI can build and test your pull request before it ever touches the master branch. You cannot ever run into the case that a past local commit is not compatible if you do it right (simply because you can fix everything locally before ever pushing to your hub). – Wilbert May 24 '16 at 08:02
  • When I wrote about trusting the merge, I was referring to how it all fits together. Sure auto merge and ci and tests can tell you if it all "works", but you still need eyes to make sure your merge is not breaking previous changes--and fit does not fix that issue. This is all folderol, as the real problem is the hours I spend with the issues git has. At this time I don't trust my repository which means I need to keep copies of it to make sure I don't lose work-- assuming I can find it again. Git is everything I have come to expect from the open source community...masochistic pain. – jlo-gmail May 24 '16 at 12:39
  • Given that GitHub is the largest source code host in the world, and Microsoft decided to use git even for TFS and put the legacy TFS source control into maintenance mode, maybe the problem lies not solely within git ;). Anyway, I was just trying to help, use whatever suits you best. – Wilbert May 25 '16 at 09:54
  • Must be more of that "learing curve"; this one is biting me now :( http://stackoverflow.com/questions/23867877/gitlab-6-9-0-hook-declined-to-update-refs-heads-master --- with tfs I do not have these kinds of problems - it just works. – jlo-gmail Jun 28 '16 at 22:16
  • More of that "learning curve": http://stackoverflow.com/questions/33330771/git-lfs-this-exceeds-githubs-file-size-limit-of-100-00-mb – jlo-gmail Jun 28 '16 at 22:31

2 Answers2

8

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 :)

rmtheis
  • 5,992
  • 12
  • 61
  • 78
wemu
  • 7,952
  • 4
  • 30
  • 59
  • -- Path length restrictions have more to do with Windows API than anything else. I agree with CI for Java, though it has been improving. – Ryan Riehle Apr 29 '14 at 03:12
  • You should probably look at the git extensions gui client for windows. It's amazingly simple to use, offers advanced functionality such as per-line staging and resetting, is fully open source and free. – Wilbert Jul 11 '16 at 14:24
4

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)
Florian Bösch
  • 27,420
  • 11
  • 48
  • 53
  • Git is wasting more of my time that is conscionable -- the problems are usually related to large files. So I would have to say, if you plan on using any files large than pick something else. – jlo-gmail Jun 28 '16 at 22:34