Git vs Team Foundation Server [closed]

Answer 1

Original: @Rob, TFS has something called "Shelving" that addresses your concern about commiting work-in-progress without it affecting the official build. I realize you see central version control as a hindrance, but with respect to TFS, checking your code into the shelf can be viewed as a strength b/c then the central server has a copy of your work-in-progress in the rare event your local machine crashes or is lost/stolen or you need to switch gears quickly. My point is that TFS should be given proper praise in this area. Also, branching and merging in TFS2010 has been improved from prior versions, and it isn't clear what version you are referring to when you say "... from experience that branching and merging in TFS is not good." Disclaimer: I'm a moderate user of TFS2010.

Edit Dec-5-2011: To the OP, one thing that bothers me about TFS is that it insists on setting all your local files to "read-only" when you're not working on them. If you want to make a change, the flow is that you must "check-out" the file, which just clears the readonly attribute on the file so that TFS knows to keep an eye on it. That's an inconvenient workflow. The way I would prefer it to work is that is just automatically detects if I've made a change and doesn't worry/bother with the file attributes at all. That way, I can modify the file either in Visual Studio, or Notepad, or with whatever tool I please. The version control system should be as transparent as possible in this regard. There is a Windows Explorer Extension (TFS PowerTools) that allows you to work with your files in Windows Explorer, but that doesn't simplify the workflow very much.

Answer 2

People need to put down the gun, step away from the ledge, and think for a minute. It turns out there are objective, concrete, and undeniable advantages to DVCS that will make a HUGE difference in a team's productivity.

It all comes down to Branching and Merging.

Before DVCS, the guiding principle was "Pray to God that you don't have to get into branching and merging. And if you do, at least beg Him to let it be very, very simple."

Now, with DVCS, branching (and merging) is so much improved, the guiding principle is, "Do it at the drop of a hat. It will give you a ton of benefits and not cause you any problems."

And that is a HUGE productivity booster for any team.

The problem is, for people to understand what I just said and be convinced that it is true, they have to first invest in a little bit of a learning curve. They don't have to learn Git or any other DVCS itself ... they just need to learn how Git does branching and merging. Read and re-read some articles and blog posts, taking it slow, and working through it until you see it. That might take the better part of 2 or 3 full days.

But once you see that, you won't even consider choosing a non-DVCS. Because there really are clear, objective, concrete advantages to DVCS, and the biggest wins are in the area of branching and merging.

Answer 3

If your team uses TFS and you want to use Git you might want to consider a "git to tfs" bridge. Essentially you work day to day using Git on your computer, then when you want to push your changes you push them to the TFS server.

There are a couple out there (on github). I used one at my last place (along with another developer) with some success. See:

https://github.com/spraints/git-tfs

https://github.com/git-tfs/git-tfs

Answer 4

After some investigation between the pro and cons, the company I was involved with also decided to go for TFS. Not because GIT isn't a good version control system, but most importantly for the fully integrated ALM solution that TFS delivers. If only the version control feature was important, the choice may probably have been GIT. The steep GIT learning curve for regular developers may however not be underestimated.

See a detailed explanation in my blog post TFS as a true cross-technology platform.

Answer 5

For me the major difference is all the ancilliary files that TFS will add to your solution (.vssscc) to 'support' TFS - we've had recent issues with these files ending up mapped to the wrong branch, which lead to some interesting debugging...

Answer 6

On top of everything that's been said (

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/4894099/172109

https://stackoverflow.com/a/4415234/172109

), which is correct, TFS isn't just a VCS. One major feature that TFS provides is natively integrated bug tracking functionality. Changesets are linked to issues and could be tracked. Various policies for check-ins are supported, as well as integration with Windows domain, which is what people who run TFS have. Tightly integrated GUI with Visual Studio is another selling point, which appeals to less than average mouse and click developer and his manager.

Hence comparing Git to TFS isn't a proper question to ask. Correct, though impractical, question is to compare Git with just VCS functionality of TFS. At that, Git blows TFS out of the water. However, any serious team needs other tools and this is where TFS provides one stop destination.