281

I introduced Git to my dev team, and everyone hates it except me. They want to replace it with Team Foundation Server. I feel like this is a huge step backwards, although I am not very familiar with TFS. Can someone with experience compare branching support on TFS to Git branching? Also, in general, what are the pros and cons of TFS? Am I going to hate it after using Git for a few years?

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
Jacko
  • 12,665
  • 18
  • 75
  • 126
  • 27
    You face an uphill battle on this one. Git is nowhere near as mature as svn/hg/tfs on Windows, which doesn't bother git veterans much, but is a major headache for newcomers. – Marcelo Cantos Dec 11 '10 at 04:03
  • possible duplicate of [What are the differences between TFS, SVN and GIT?](http://stackoverflow.com/questions/2589801/what-are-the-differences-between-tfs-svn-and-git) – Greg Hewgill Dec 11 '10 at 04:15
  • 1
    @Marcelo: this may have been true a year ago, but the tools are catching up on windows: I have a pretty sweet configuration: MsysGit + KDiff3 + Git Extensions + Git Source Control Provider VS plugin. There is good integration with visual studio, and Git Extensions is an excellent app. And KDiff3 is a super merge tool that supports 3 way merge. So, normal workflow can all be done without dropping down to the command line. – Jacko Dec 12 '10 at 00:22
  • 9
    @Jacko: I've been evaluating git-for-Windows over the last few weeks. While it has markedly improved since I last looked at it about a year ago, it is still a long way off being ready for prime time with typical Windows developers. E.g., the VS plugin is frankly woeful. It is nothing but a bunch of menu options under the main menu bar, which silently fail if the solution is selected instead of a project. I can't get the commit tool to index hunks and lines, which is the main reason I use git, and getting to git gui (which is a complete atrocity, from a usability POV) is awkward at best. – Marcelo Cantos Dec 12 '10 at 02:57
  • @Marcelo: very interesting points: our current workflow is not sophisticated enough to require indexing hunks and lines, so this issue didn't come up. Although, the guy who develops Git Extensions is very open to feature requests, so you could open an issue with him. Git Gui: never used it much so can't comment. And yes, the plugin is pretty primitive, but we use it mainly for a quick compare and file history: rest of the workflow is done in Git Extensions. May I ask what environment you are comparing to git-for-windows? – Jacko Dec 12 '10 at 13:11
  • @Jacko: I'm sure git extension will eventually be awesome, but right now it's 180° in the opposite direction to what I want from a shell extension, which a few feature requests won't fix. TortoiseGit is the right direction but, AFAICT, it doesn't even expose the index, let alone hunk/line-level staging. After the review, I decided to put my team on Mercurial. It is easy to install and manage, and it is very easy to educate the other developers, especially the business owner who is also technical, but codes infrequently. He was the deciding factor; otherwise we would have made do with git. – Marcelo Cantos Dec 12 '10 at 21:28
  • 7
    I'll be honest with you, though; it kills me to drop git. Contrary to the popular view out there that the two are on par, I find git's model to be much more powerful and logical. Mercurial has nothing to match git's index, and I hate its approach to branching. Git's concept of labels that you move around and synchronise between repos is very elegant. Mercurial's bookmarks are the only thing that comes close and they're a PITA to set up for everyone. The bottom line, though, is that success is more likely with svn→Mercurial than svn→git, given the staff and relative maturity of the tools. – Marcelo Cantos Dec 12 '10 at 21:32
  • Very interesting, thanks Marcelo. I had bad experience with TortoiseGit; this was my first choice as a Gui for the team, and the – Jacko Dec 13 '10 at 23:57
  • ...and they got very confused using it. I would think that Git's approach of content over files would more suit a global view like Git extensions vs. a shell extension like TortoiseGit. – Jacko Dec 13 '10 at 23:58
  • 5
    yes, Git rules when it comes to power and elegance. But, not everyone is ready for it. – Jacko Dec 13 '10 at 23:58
  • @Jacko: So one year later, what is your take? I'm currently using TFS, which I really like thanks to its great integration with VS and reliability, but heard of Git thanks to AppHarbor and am thinking of switching some projects to it... – James Reategui Dec 03 '11 at 21:04
  • 8
    @JamesReategui: I personally think (http://stackoverflow.com/a/11362998/520162) that the integration of a VCS in an IDE is a meander. Imagine if you're switching your main IDE tomorrow. What if you drop VS for Eclipse? Are you **really** willing to learn a new VCS integration? Git is great on the command line (http://stackoverflow.com/a/5645910/520162). Learn it and you'll discover an incredibly powerful world of version control. – eckes Jul 13 '12 at 22:20
  • 4
    @eckes The chances you would change your IDE are very small when you are a fulltime .NET developer. – riezebosch Apr 25 '13 at 08:50
  • 3
    @riezebosch with a very limited scope, this might hold true. But I've heared of people that know more than one language... – eckes Apr 25 '13 at 11:09
  • 2
    Interesting that the most upvoted questions are also the first to be closed. It would appear that the things that people are passionate about (aka holy wars) are also the most destructive questions. (I love this profession) – Armstrongest May 29 '14 at 16:27
  • 2
    Actually what is interesting here is the history lesson: 1. In 2010 Stackoverflow had not gone over to the Close All The Things side. 2. In 2012, they had, and they went back and closed everything retroactively that had answers and upvotes so that it wouldn't be pointed to as evidence that they were inconsistent, when in fact, they were inconsistent. – Warren P Jan 21 '16 at 13:55
  • GIT takes more time to play – Ali.Mojtahed May 15 '16 at 12:55
  • 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:06
  • Shouldn't the question be **Team Foundation Version Control (TFVC)** vs **Git**? **Team Foundation Server (TFS)** is a lot more than just a version control system, and **Git** can be used with **TFS**. – James Wierzba Nov 27 '17 at 21:26
  • @jlo-gmail That doesn’t sound like anything I’ve ever seen in 8 years of using Git. In particular, I’ve never seen a commit fail. I strongly suggest posting a question to Stack Overflow (or other forum) next time you have a problem. Some people find Git hard to learn (I didn’t), but it is powerful and stable. – Marnen Laibow-Koser Jun 08 '18 at 00:53
  • git for windows is a lot more polished now, and I use it daily with no problems – KetZoomer Oct 22 '20 at 23:50

9 Answers9

290

I think, the statement

everyone hates it except me

makes any further discussion waste: when you keep using Git, they will blame you if anything goes wrong.

Apart from this, for me Git has two advantages over a centralized VCS that I appreciate most (as partly described by Rob Sobers):

  • automatic backup of the whole repo: everytime someone pulls from the central repo, he/she gets a full history of the changes. When one repo gets lost: don't worry, take one of those present on every workstation.
  • offline repo access: when I'm working at home (or in an airplane or train), I can see the full history of the project, every single checkin, without starting up my VPN connection to work and can work like I were at work: checkin, checkout, branch, anything.

But as I said: I think that you're fighting a lost battle: when everyone hates Git, don't use Git. It could help you more to know why they hate Git instead of trying them to convince them.

If they simply don't want it 'cause it's new to them and are not willing to learn something new: are you sure that you will do successful development with that staff?

Does really every single person hate Git or are they influenced by some opinion leaders? Find the leaders and ask them what's the problem. Convince them and you'll convince the rest of the team.

If you cannot convince the leaders: forget about using Git, take the TFS. Will make your life easier.

Community
  • 1
  • 1
eckes
  • 64,417
  • 29
  • 168
  • 201
  • 24
    Bang on, eckes. They blame me whenever something goes wrong. Not themselves for failing to learn how it works. For me, Git is as close to perfection as I've ever experienced in a version control system. – Jacko Dec 12 '10 at 02:16
  • Of course, I've been using it for a few years now. – Jacko Dec 12 '10 at 02:16
  • 2
    Hold people accountable for their mistakes. People are rarely held accountable and this creates the safety net that allows them to blame others for their own faults. – James Dunne Dec 29 '10 at 16:57
  • 16
    On the other hand TFS includes defect/work item tracking, reportings, ... and other functions. So Git vs TFS on VCS functionality only is rather missing the point of TFS. – Richard Mar 18 '11 at 12:38
  • 1
    Git is a gem of an open source development tool. In fact, gem is an understatement--it is a work of art. But for the enterprise, I'm starting to have my doubts. Just the fact that once something gets into the commit tree it can NEVER be removed makes it less than ideal for enterprise use. – Dan Solovay Feb 09 '12 at 03:28
  • 5
    @Dan see rebase, filter-tree... – Artefacto Mar 16 '12 at 10:48
  • 7
    @Artefacto I know, but then all the commit tags change, and all metadata (code review discussions, etc.) are orphaned or need to be updated. Nevertheless, a month with TFS has persuaded me that it is not in Git's league as a version control system. Git frees the developer to be productive in ways that have to be experienced to be understood. The branch as scratch pad metaphor is wicked powerful. – Dan Solovay Mar 21 '12 at 04:23
  • 6
    @Richard I'd argue that's a downside to TFS: once you're in, you're all in. It does everything mediocre and doesn't give you a choice about it. There are far, far better tools for tracking work items, reporting, and project management. – Ben Collins May 09 '12 at 03:38
  • 2
    "The branch as scratch pad metaphor is wicked powerful." Geez, you'd thing some of you people have never heard of TFS's "Shelve" feature... – Alex Dresko Sep 18 '12 at 18:39
  • @Richard see [TFS is destroying your development capacity](http://www.derekhammer.com/2011/09/11/tfs-is-destroying-your-development-capacity.html) for arguments against TFS as ***both*** Version Control and Application Lifecycle Management tool. –  Aug 06 '13 at 07:19
  • 4
    @cupcake: That article has a load of errors even in the first page (even without considering the changes in the last three years). Any way 1. No one suggests TFS is the right answer for everyone. 2. TFS, in the next version, includes Git: which kind of changes the context of this question to such an extent to invalidate all the existing answers. (BTW, these days I use both: neither is perfect, neither will work for everyone.) – Richard Aug 06 '13 at 08:10
  • 5
    @AlexDresko "shelves" in TFS seem to be the equivalent of "stash" in git. While they are useful for small changes, they hardly work for 3+ days of work, and for consecutive changes, etc. – ANeves Oct 16 '13 at 12:56
  • 2
    + just for the methodology of the answer. good psychology assessment! – CME64 Sep 14 '15 at 12:08
  • 3
    I found that the two reasons given in this answer (local repo, auto backup) are pretty weak. A strong software company is already backing up their repo... and with today's connectivity, and VPNs being such a snap, there's no barrier there to productivity. – Craig Brunetti Apr 11 '18 at 15:08
  • 1
    Are those really the two big benefits? If that's it, I don't see the appeal. I mean, for #1, if we lose our TFS repository server (and the offsite backups we do of all of our servers) we have MUCH bigger problems than just code history. And for #2, we are not allowed to have code on an unconnected machine anyway - all of our machines are VMs. If I don't have an internet connection, I have no PC period. – Sean Worle May 08 '19 at 23:44
  • 1
    These are not only weak arguments, that they imply tfvc cannot do these things is patently **false**. It's not right for misinformation to carry this much influence. I flagged this for moderator intervention so these examples can be removed. – StingyJack Mar 04 '20 at 13:28
118

The key difference between the two systems is that TFS is a centralized version control system and Git is a distributed version control system.

With TFS, repositories are stored on a central server and developers check-out a working copy, which is a snapshot of the code at a specific point in time. With Git, developers clone the entire repository to their machines, including all of the history.

One benefit of having the full repository on your developer's machines is redundancy in case the server dies. Another nice perk is that you can move your working copy back and forth between revisions without ever talking to the server, which can be helpful if the server is down or just unreachable.

To me, the real boon is that you can commit changesets to your local repository without ever talking to the server or inflicting potentially unstable changes on your team (i.e., breaking the build).

For instance, if I'm working on a big feature, it might take me a week to code and test it completely. I don't want to check-in unstable code mid-week and break the build, but what happens if I'm nearing the end of the week and I accidentally bork my entire working copy? If I haven't been committing all along I stand the risk of losing my work. That is not effective version control, and TFS is susceptible to this.

With DVCS, I can commit constantly without worrying about breaking the build, because I'm committing my changes locally. In TFS and other centralized systems there is no concept of a local check-in.

I haven't even gone into how much better branching and merging is in DVCS, but you can find tons of explanations here on SO or via Google. I can tell you from experience that branching and merging in TFS is not good.

If the argument for TFS in your organization is that it works better on Windows than Git, I'd suggest Mercurial, which works great on Windows -- there's integration with Windows Explorer (TortoiseHg) and Visual Studio (VisualHg).

Rob Sobers
  • 20,737
  • 24
  • 82
  • 111
  • 6
    If you do think about going with Mercurial, Joel Spolsky has an excellent tutorial site for educating your team: http://hginit.com/ – Martin Owen Dec 11 '10 at 08:54
  • Thanks, Rob. It will be a sad day indeed if/when we switch. But, it is looking like this is not a fight worth fighting. At least I have Github for my private, OSS projects. – Jacko Dec 12 '10 at 02:01
  • Thanks, Martin. That link was very interesting. – Jacko Dec 12 '10 at 02:12
  • 1
    I am currently lobbying an OSS project I am contributing to to switch to a DCVS. Gonna use that Spolsky link for ammunition :) – Jacko Dec 12 '10 at 13:13
  • 3
    It might be worth mentioning that git is perfectly capabable of emulating a centralised system, and it's common to have a primary git server for all users, you just don't *have* to do it that way. – Tim Abell May 12 '11 at 13:26
  • 10
    if you are working on a piece of functionality that might break other stuff - couldn't you just create a branch in TFS? Sure - the branch is on a central server - but does that really matter? It seems like you can effectively do the same thing in both - it seems like more of a question of which IDE you are using and how well integrated the version control system is with it - – William Feb 22 '14 at 19:52
  • 14
    If you are working on a big feature that potentially could interrupt the team it is recommended to use a feature branch and then when ready merge down into the development branch. – Mike Cheel Aug 12 '14 at 20:04
  • 10
    @MikeCheel This is a great comment. You could also create a **Shelve** of your code every day and delete them when you finally check-in your feature (but the branching idea is a better way to do it) – RPDeshaies Nov 28 '14 at 19:16
  • Git is my go to, you can do private checkin via shelveset concept in dvcs. This one is similar to stashing with the nice benefit of ability to share with others – Andrew Stakhov Feb 15 '19 at 15:33
  • 2
    How do you avoid the problem of working for a week on changes, committing locally, and then before you can push them, your developer box dies? People talk about the advantage of DVCS being that there isn't just one copy of your repository that could be lost, but I'm MUCH more worried that my workstation could die and not be recoverable than I am that our enterprise TFS server will. – Sean Worle May 08 '19 at 23:54
  • Nice answer, Rob. – Matt Smith Sep 18 '19 at 19:39
87

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.

Charlie Flowers
  • 17,338
  • 10
  • 71
  • 88
  • 4
    Thanks, Charlie. I know it, and you know it, but it is hard to get through to people who say things like "integration of source control with Visual Studio is the most important feature for me" – Jacko Feb 07 '11 at 21:41
  • 59
    I know. A friend and I were throwing this analogy around -- imagine you need a serious relational database. You evaluate Sql Server, Oracle, and MS Access. You end up choosing Access because it has the nicest GUI, in spite of the fact that it can't scale, doesn't enforce referential integrity very well, etc. Branching and Merging are the absolute meat and potatoes of a version control system. Any other feature is just a little bling on the side. But people are making choices based on the bling. – Charlie Flowers Feb 08 '11 at 08:21
  • 18
    While I tend to agree with your statements, I don't see why Git's branching and merging is "better" just because it is a "distributed" system. I'm not sure that being a DVCS has anything to do with its ability to merge. I'd love an explanation of why merging is easier in a distributed system. In my experience, which is primarily Git and Svn, merging in SVN is terrible not because it is a centralized VCS, but because it doesn't properly track revisions across branches like GIT does. – CodingWithSpike May 16 '11 at 13:15
  • 1
    @rally25rs, in a nutshell, DVCSs *have* to be good at branching and merging, because they support usage scenarios involving "promiscuous" merging. Linux has hundreds (thousands?) of developers, all pulling from each other, merging with each other, etc., & from all that activity, occasionally a select few package up some code & call it a "release". Even if the intent is not to maintain 2 different lineages of code, everything in a DVCS is a branch. Your local repo is a branch. Mine is a different branch. At any time, you can pull from me or me you, as well as "upstream" or anywhere else. – Charlie Flowers May 19 '11 at 23:19
  • 2
    @rally25rs (continued)- "How" are DVCSs good at merging? Several reasons, including the fact that they maintain info about "commits", so when you merge A into B they know which "commits" from A are already in B, and which aren't. And if A is the somewhere on a long lineage, and so is B, then knowing which commits you already have and which you don't is huge. But this is only one of the things that makes DVCSs better at merging, and I'm out of space. – Charlie Flowers May 19 '11 at 23:22
  • 2
    @Charlie - I agree with your statements, especially those about tracking commits (this is where SVN absolutely sucks, IMO). My only point was that just because a certain VCS is centralized, doesn't mean it is inherently bad at branching and merging. Someone could certainly write a CVCS that was better at branching/merging than Git, purely by writing better merge routines that resolved conflicts better. The actual distributes vs centralized is somewhat irrelevant. What is relevant is how the VCS tracks changes and resolves merges. Again, not arguing your statements, just arguing the semantics. – CodingWithSpike May 20 '11 at 15:34
  • 8
    @rally25rs -- I agree with most of that. There's no reason a VCS can't be good at merging too. There just aren't any yet (that I know of). But the part I disagree with is "purely by writing better merge routines that resolved conflicts better." The secret sauce is not in better-smarter merge routines, but in taking a fundamentally different approach to what information you store in the repo and how you organize it. Mainly, making Commits the foundation of the internal state. Commits are not just a cool bolt-on ... they are the foundation of the capabilities. – Charlie Flowers May 26 '11 at 00:23
  • 1
    @Charlie - "Mainly, making Commits the foundation of the internal state." yes, yes, and more yes. I can't agree with that enough. The fact that SVN doesn't do that makes it practically unusable in a complex situation. – CodingWithSpike May 26 '11 at 13:33
  • 11
    @rally25rs totally agree re: commits being the atomic unit of work. Not only do most centralized systems not organize the data this way, but they discourage the moment-to-moment kind of work the developers have to do in order to make really good branch-and-merge work. Distributed systems encourage what I call "apposite" commits (self-contained, small commits of relevant work with good descriptions) and centralized systems encourage what I call "diff bombs" where you hole up in a cave until you are ready and then drop days (or weeks) worth of work on the system. Guess which kind merges best? – Ben Collins Oct 06 '11 at 19:40
  • 1
    @Ben Collins - that is a great comment and right on the money. Not only is git better at merging huge "diff bombs" because it has a superior internal structure, but it also encourages a much better unit-of-work-sized commit, which will merge much more easily. These are 2 separate objective reasons that git is better at merging. – Charlie Flowers Oct 09 '11 at 16:40
  • RE: "Merge Enhancements in TFS" - I think you'll see the TFS product team has worked hard over the last several months looking at different merge conflicts that arise. Actually, TFS "11" includes quite a few improvements in this space. Brian Harry went through several of those merge enhancements here: http://blogs.msdn.com/b/bharry/archive/2011/08/31/merge-enhancements-in-tfs-11.aspx – Ed Blankenship Mar 21 '12 at 12:07
  • Wow! Today, Microsoft announced that Visual Studio and TFS will have GIT SUPPORT! http://news.ycombinator.com/item?id=5140697 – Charlie Flowers Jan 31 '13 at 22:38
  • 3
    @BenCollins Three years later, late to the party - but upvote for the term "diff bombs". Laughed out loud at that. –  Dec 24 '14 at 15:44
  • @BenCollins But how do you counter the solution that, with a centralized VCS, you just create a new branch and put lots of small commits into it? That would seem to deal with the "diff bomb" problem. – Jez Feb 12 '15 at 11:24
  • 1
    @Jez, it depends entirely on how merging is implemented. Possibly for historical reasons, centralized VCSs tend to discourage that kind of pattern, and they tend to implement merging as "diff this against that and then try to apply it to that", which is a pretty naive way to do merging. With large diffs, the odds of conflicting are high. Git *encourages* apposite (small, self-contained, germane) by making merges all but painless. – Ben Collins Feb 23 '15 at 21:21
  • This seems insane to me. Everyone who's worked in a large group knows that smaller commits, more often, provide better results than larger commits less often. The same goes for merging... smaller merges every day, or every week, are better for everyone than merges once a sprint. So how do people simultaneously support "I can commit all I want, because it's local" AND "merges are easy", when the whole point of comitting local is to AVOID the kinds of build issues one would get by merging with everyone else's changes? – Craig Brunetti Apr 11 '18 at 15:10
  • @CraigBrunetti Since merges are easy, I can do then whenever I want. But since I have local commits, I can do those merges when it makes sense for me, not on someone else’s schedule. That means I can (and do!) merge frequently, but do so at logical points for my local work. That is, local commits actually *support* the practice of frequent merges by making the merges less of a pain. Does that answer your question? – Marnen Laibow-Koser Jun 13 '18 at 17:29
  • @MarnenLaibow-Koser no, because that's exactly what TFS workspaces allow as well. Besides, that wasn't the point... if merges truly are easy, there there seems little reason to resist merging to a common space, so that the software can grow collaboratively. And "frequently" is such a relative term... I'm "getting latest", which is like a local-workspace-rebase, many times per day (2-10?). Are you "frequently" merging at that speed? Would that truly align with GIT's intent? – Craig Brunetti Jun 14 '18 at 18:33
  • @CraigBrunetti I’ve never used TFVC; I can’t provide direct comparisons there. But I think you’re missing a key fact here: not every local commit I make is going to wind up in master. I often make several experimental local branches when I’m figuring out the best way to implement something. That way I have version control on my experiment, but I don’t have to put the failed attempts into the public repo. Also: “are you frequently merging at that speed?” Yes, I merge master into my local branch *at least* once a day, often more. But I don’t merge my local branch into master till it’s complete. – Marnen Laibow-Koser Jun 14 '18 at 18:43
  • @CraigBrunetti Also, I’ve never seen your hypothetical situation of “merges once a sprint”; you’re right that that would be bad. Features should be small, so it’s rare for a feature branch to live for more than a day or two. Then it is reviewed and merged into master immediately upon completion (and master has already been merged into it frequently during development). On a team of reasonable size, that usually means multiple branches get merged into master every day. – Marnen Laibow-Koser Jun 14 '18 at 18:49
  • @MarnenLaibow-Koser alright, but I'm starting to see a pattern... in terms of the word "complete", what does that mean? In our TFS model, it means that we've given QA a chance to smoke/buddy test our feature branch, and then we merge the work into a "main" (though in larger scenarios, it's a DEV main, until a Story is actually Accepted) where QA has at it again. Is this similar to your experience? – Craig Brunetti Jun 29 '18 at 01:42
  • And in truth, using TFS, I'm throwing away branches all the time as well, esp. for experiments. Good practice regardless of the tech, right? I suppose the difference is, since my branch is under TFS, the company gets to own my experiment without me thinking about it (since it's their IP!), whereas local experiments can be lost, can be forgotten, and that doesn't feel as transparent to me. "We could branch at the server all the time, too" would be a valid response, but then, is that really what GIT patterns preach? – Craig Brunetti Jun 29 '18 at 01:45
  • One last thing... when merges are easy, then merging small pieces of work, even "parts of a feature", when the area of code involved in that feature is being changed concurrently by others, means that we can feed off of each other's progress, constantly. I commit to our Main often, because it means that access to my work is fast, and when there are problems, they are found fast; and I resolve them before others rebase. For me, failing fast is what Agile's all about! :) – Craig Brunetti Jun 29 '18 at 01:49
  • @CraigBrunetti “in terms of the word "complete", what does that mean?” Whatever makes sense for your development process; in my case, that’s usually been all tests passing and code review satisfactory, but there’s no reason that a formal QA process wouldn’t fit here too if desired. “local experiments can be lost, can be forgotten, and that doesn't feel as transparent to me” Sure, that’s true, but it’s not a big deal in practice. This is not like basic research where the company needs every last lab note. – Marnen Laibow-Koser Sep 14 '18 at 12:18
  • @CraigBrunetti “when the area of code involved in that feature is being changed concurrently by others, means that we can feed off of each other's progress, constantly” I don’t want to incorporate others’ changes till I know that they work by themselves. There’s no advantage to feeding off incorrect code. Therefore I want code to be verified (whatever that means in practice) before it enters master. “I commit to our Main often, because it means that access to my work is fast, and when there are problems, they are found fast” So you’re introducing problems into Main? No thanks. – Marnen Laibow-Koser Sep 14 '18 at 12:23
  • @MarnenLaibow-Koser, you check in code that doesn't work? That's crazy talk. – Craig Brunetti Sep 17 '19 at 20:05
  • I don't suppose people have ever had "local experiments" turn into "hey that's a neat tool, maybe it's worth not losing". When it's checked in, *you* don't have to be the one to product-ize it, when others want more of it than you do. – Craig Brunetti Sep 17 '19 at 20:06
  • @CraigBrunetti “Check in” has no meaning in Git. But no, I don’t push code that doesn’t work, nor do I commit it unless I immediately amend that commit. – Marnen Laibow-Koser Sep 17 '19 at 20:07
  • You're splitting hairs. You either commit code to a repo (central or local, doesn't matter) that you know doesn't work, or you don't. And in turn, you expect others to follow similar behavior. In TFS, there are commits, for stuff we know works, and there are Shelves, for stuff we think may not. Both are centralized, can't be lost, CAN be viewed by anyone. I want my code to stay as close to MAIN as possible because I know the stuff that made it there, works, and I want my work to be compatible with others' successes. I think this is the key difference... who's work is more important. – Craig Brunetti Sep 17 '19 at 20:11
  • @CraigBrunetti I’m not splitting hairs. I’m just trying to avoid using ambiguous terminology. In general I expect a commit to be a known good state of the codebase. I also try to stay close to master, but by working in a private branch I have control over when I integrate (which I do frequently). • ‘I don't suppose people have ever had "local experiments" turn into "hey that's a neat tool, maybe it's worth not losing".’ If that happens, then it’s time to make a pull request. • “I think this is the key difference... who's work is more important.” I can’t make any sense of that remark. – Marnen Laibow-Koser Sep 17 '19 at 21:29
45

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.

Community
  • 1
  • 1
Lee Grissom
  • 9,705
  • 6
  • 37
  • 47
  • 2
    This answers the question, it shouldn't be a comment, even if you had the rep. – SingleNegationElimination Feb 06 '11 at 22:11
  • git equivalent to shelving: create a branch, check in to that, push that to server. when you are done, merge with or rebase onto the main branch and push that. – Tim Abell May 12 '11 at 13:25
  • @TimAbell, that is correct. Your suggestion can be applied using any version control system. The advantage of your suggestion is that you get "true" revision history of your "off to the side" changes. Shelving in TFS was intended to be a simple, easy-to-use feature for a wide range of users. For the more rigorous developer, s/he will likely need to rely on your suggestion. – Lee Grissom Dec 06 '11 at 02:05
  • 1
    I suppose "git stash" might be more similar, however that's a local operation. Still handy for the "I'll come back to this" moments. – Tim Abell Dec 07 '11 at 10:36
  • 1
    I would also mention that TFS "11" includes much more around shelving. It is more of a "suspend work" paradigm in which not only are the version control pending changes shelved, but also the context of where you were working. For example, the open windows, solution, breakpoints, work items, etc. are all attached as metadata to the shelveset. Visual Studio now inherently can help you truly suspend work when the scenarios come up for developers. (BTW - I'm not advocating for interrupt-driven project management at all but there are certainly times where this can be useful). – Ed Blankenship Mar 21 '12 at 12:01
  • 8
    FYI - TFS "11" doesn't require the read-only bit any longer if you are using local workspaces which is the default now. It intelligently discovers what files are changed from any application. Brian Harry has some more information about the improvements here: http://blogs.msdn.com/b/bharry/archive/2011/08/02/version-control-model-enhancements-in-tfs-11.aspx – Ed Blankenship Mar 21 '12 at 12:03
  • 2
    @EdBlankenship, thank you very much for that blog link. That is excellent news to see that the read-only bit nonsense is being addressed to make using the next version of TFS much easier. – Lee Grissom Mar 21 '12 at 22:27
  • 1
    FYI: I'm pretty sure it's much easier to get into merging hell when trying to merge from a shelveset. AFAIK you can't automerge from a shelveset. – Dan Esparza Sep 12 '12 at 19:51
  • 7
    Contrary to commits in a branch like you do with Git, shelving is not easy to understand and manage. You don't know on each commit the shelving was made and you often have problems with merge (if you have since then made modifications, they are often lost). Git branch are much more powerfull and understandable than shelving. Shelving is for developpers that never experienced something else.... – Philippe Dec 13 '12 at 16:46
  • 2
    This workflow of 'checking-out' a file is reminiscent of Visual SourceSafe, as this was the common way of working; files were retrieved from SourceSafe and stored locally as read-only files. Checking out a file, or a bunch of files, could be marked as exclusive, meaning that others could see the file-set that another dev is working on, as to prevent the need for merging when branching was disabled (probably due to being a right pig in VSS). – Brett Rigby Jan 15 '14 at 12:55
  • The only way to automatically "detect" a change is to continuously validate a known checksum against all files within a solution. Easy to do in small solutions...but a BAD idea for large ones. The overhead involved in doing that would be HORRIBLE. – Prisoner ZERO Feb 27 '14 at 13:38
  • 1
    Shelving in TFS is horrible. It's slow, it doesn't let you quickly switch between branches (ie. different things you're working on), you generally do it through Visual Studio's clunky GUI, you have to remember the exact name of the shelveset if you want to update it so it "overwrites it"... give me local branching as an alternative any day. – Jez Jan 12 '15 at 14:54
  • The point of a shelveset is specifically NOT to be like a branch... TFS has branches, and they work fine under TFS' governance. Shelvesets are specifically for half-done work that you either want to back up or share temporarily. They are easy to create, share, and destroy, and you don't lose any work when your hard drive fries on you. – Craig Brunetti Apr 11 '18 at 15:13
  • @BrettRigby TFS's "checkout" action has been, for years, simply an indicator to others of intent to edit. Exclusive checkout hasn't been a real thing in TFS, ever (though the feature exists, it was to appease SourceSafe users who couldn't let go). The read-only-ness is also not a requirement. By the time of your comment, TFS had been this way for years. – Craig Brunetti Jun 29 '18 at 01:58
  • In the grand scheme of things, I think that if people are trying to use Microsoft's source control solution, and *not* use Microsoft's IDEs, then you're doing yourself a disservice. The Microsoft ecosystem has its greatest value if you're simply all-in... So if you're looking for more, maybe their ecosystem isn't for you. – Craig Brunetti Jun 29 '18 at 02:00
17

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

Jon
  • 4,746
  • 2
  • 24
  • 37
bytedev
  • 8,252
  • 4
  • 48
  • 56
  • 6
    Microsoft provides a direct integration with Git repositories and TFS now: http://blogs.msdn.com/b/bharry/archive/2012/08/13/announcing-git-integration-with-tfs.aspx – Ed Blankenship Aug 26 '12 at 14:30
  • 1
    @EdBlankenship, you might want to convert your comment to an answer. It appears to be a great solution for the OP. I'll vote for it. :) – Lee Grissom Sep 15 '12 at 20:48
  • 1
    Except if you are on another platform than Windows, you should prefer git-tfs! git-tf is far from be as good as git-tfs...And the philosophy is TFS oriented while git-tfs is more git oriented (and that's what we want!) – Philippe Dec 10 '12 at 00:19
17

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.

Community
  • 1
  • 1
Sherlock
  • 1,022
  • 8
  • 19
  • 4
    Please you can get the same tools TFS provides in any agile tool application. Rally, you name it. – PositiveGuy Sep 09 '13 at 02:37
  • 2
    While I agree in the fact that TFS has a broader objective, I would rephrase it to "it TRIES to provide a one stop destination", but it's not good enough (at least no the best option) in any of the tasks it tries to solve; so it's like a blunt Swiss knife. – slashCoder Sep 02 '15 at 16:40
  • 1
    @PositiveGuy you can't get it without work and configuration. TFS gives you the whole thing with a click. Case in point, the entire ecosystem is now available as a cloud service, with zero config required. If I can get version control, scrum support, automated builds, test lab and test plan management, all integrated out of the box with themselves AND a corporate LDAP (lie AzureAD), for $10/mo, why in my right mind would I go trying to paste pieces together on my own? – Craig Brunetti Jun 29 '18 at 02:05
  • 1
    @slashCoder how could any full suite be expected to be the best at each piece? Does the cost of its non-best-ed-ness really outweigh the cost of having to manage components' integration on your own? ... maybe for some places it does, I can see that. But it's pure overhead to have to run such things. What happens if your corporate GIT is running fine, but your JIRA instance goes down, and your Jenkins upgrade doesn't fly? Right? It's like juggling chainsaws. On fire. Semi-blindfolded. :) :) – Craig Brunetti Jun 29 '18 at 02:09
  • > What happens if your corporate GIT is running fine, but your JIRA instance goes down, and your Jenkins upgrade doesn't fly? Right? It's like juggling chainsaws. On fire. Semi-blindfolded ---- So your point is that single point of failure is more reliable than multiple applications running separately? :-) – atb00ker Aug 12 '20 at 11:50
14

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.

Pieter Gheysens
  • 161
  • 1
  • 3
  • 3
    Perhaps, but each part of TFS is bad and difficult to administrate (in fact, you need a real administrator for TFS). Look Git>TFS(VCS), Jenkins>TFS(CI), nunit or xunit > mstest, IceScrum or ... > TFS(Project Management). TFS is a good idea at the beginning, until you use it!!! – Philippe Dec 13 '12 at 16:58
  • 1
    why do you need TFS, just get a good agile app. And then use Git or subversion and you're on your way. TFS just gets in your way by bogging you down with problems. – PositiveGuy Sep 09 '13 at 02:38
  • Update: TFS 2013 (server) [and VS12-13) now supports git for version control. So you can get the best of both worlds – DarcyThomas Dec 20 '13 at 00:35
  • 2
    Sure, it's nice to have a fully integrated ALM. But not at the expense of flexibility. IMO. an ALM should be constructed with as much "best of breed" technology as possible ... or at the very least, the flexibility to integrate best of breeds, as they are likely to change over time. Choosing TFS is basically putting a stake in the ground, saying "microsoft is going to win at all aspects of my ALM", which is silly. I've used Git w/ Jira, for example, which allowed me to update / close issues based on my commit message. In my experience (plenty with TFS too), this is a vastly superior workflow. – Scott Silvi Jan 23 '14 at 16:43
  • 1
    Sidebar - even with TFS / Git integration, you're basically saying "lets farm out VCS to Git, while keeping our issue tracking" - fundamentally no different than using Git w/ any other issue tracking software. So I'm not sure the ALM argument is valid anymore, given Microsofts attempts at flexibility (which I applaud). – Scott Silvi Jan 23 '14 at 16:44
  • "steep GIT learning curve" - I think this is key. TFS source control is simple and easier to learn. – Colin Apr 27 '16 at 21:59
13

The whole Distributed thing of Git is really really great. it gives a few features Shelvesets don't have (in the current product) such as local rollback and commit options (such as Eclipse's localhistory feature). You could alleviate this using developer branches, but lets be honest, many developers don't like branching and merging one bit. I've been asked to turn on the old style "exclusive checkout" feature in TFS a few times too often (and denied it each and every time).

I think many large enterprises are quite scared to allow a dev to just bring the whole history into a local workspace and take it with them (to a new employer for example)... Stealing a snapshot is bad, but taking away a whole history is even more troublesome. (Not that you couldn't get a full history from TFS of you wanted it)...

It's mentioned that it's a great way to backup, which is great for open source again where the original maintainer might stop to care and removes his version, but for a enterprise plan this again falls short for many enterprises as there is no clear assignment of responsibility to keep backups. And it would be hard to figure out which version to use if the main 'project' vanishes somehow. Which would tend to appoint one repository as leading/central.

What I like most about Git is the Push/Pull option, where you can easily contribute code to a project without the need to have commit rights. I guess you could use very limited users and shelvesets in TFS to mimic this, but it isn't as powerful as the Git option. Branching across team projects might work as well, but from an administrative perspective it's not really feasible for many organisations as adding team projects adds a lot of administartive overhead.

I'd also like to add to the things mentioned in the non source control area. Features such as Work Item Tracking, Reporting and Build Automation (including lab management) greatly benefit from a central leading repository. These become a lot harder when you use a pure distributed model, unless you make one of the nodes leading (and thus go back to a less distributed model).

With TFS Basic coming with TFS 11, it might not be far off to expect a distributed TFS which allows you to sync your local TFS basic to a central TFS in the TFS 12+ era. I'll put my vote for that down in the uservoice!

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • You'll also be interested in this new feature brought to you by Microsoft: http://gittf.codeplex.com/ – jessehouwing Nov 29 '12 at 13:35
  • 1
    use git-tfs. For the moment, it's way better than git-tf!!! https://github.com/git-tfs/git-tfs – Philippe Dec 13 '12 at 16:53
  • 3
    This whole answer is quickly getting out-dated. Microsoft has added Git support to Team Foundation Service and will add support for Git to the next major release of Team Foundation Server. – jessehouwing Feb 03 '13 at 20:36
  • 1
    @Philippe: I've tried both. A couple differences: 1) git-tf is cross-platform, whereas git-tfs only runs on Windows. 2) git-tfs rewrites commit descriptions when you "push" to include the changeset number, whereas git-tf leaves your local commit hashes intact. – Joey Adams Oct 31 '13 at 23:12
  • @JoeyAdams 1) +1, that's the only good reason to choose git-tf 2) You could also do that with git-tfs using `checkin` command (instead of rcheckin). But I prefer rcheckin because it's more the git way to do things and that's why we choose to use git ;) – Philippe Nov 02 '13 at 00:22
  • If all of your work is local, because its advantageous to commit local, and your hard drive burns out, you lose time. if you had committed to central, or shelveset'd, you lose nothing. Given today's cloud-oriented world, what's more reliable for an enterprise... cloud-based source control systems, or your "company-paid-as-little-as-they-had-to" workstation? – Craig Brunetti Apr 11 '18 at 15:15
  • @CraigBrunetti if you had created a fork on the remote server and had pushed regularly to that you'd have no issues whatsoever. Using a central server is not impossible with Git. In fact you can use as many remote servers as you'd want. – jessehouwing Apr 11 '18 at 18:57
  • @jessehouwing you mean, like creating a branch in TFS and pushing regularly to that? Seems like the same thing. – Craig Brunetti Jun 14 '18 at 18:36
  • GIT feels very much like a situation that compels an "owner" to accepts "pulls", meaning you have an owner, and that "pulled" work isn't an enterprise's business until it's ready to be pulled. TFS has felt like an enterprise sandbox which encourages everyone to have their work owned and persisted. Both mechanisms allow centralization and distributed processes... the only difference I see is ownership... and in today's scrum world, ownership is by teams, not by single authorities. – Craig Brunetti Jun 14 '18 at 18:52
  • You can make the team pull request approves, by default they all are. – jessehouwing Jun 14 '18 at 20:53
  • The owning is mostly in open source projects, where there are one or more maintainers. That's where many of the patterns stem from. There is no need to mimic that behavior in the way you handle pull requests. You could set them to self approve allowed in policy. – jessehouwing Jun 14 '18 at 20:54
9

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

Paddy
  • 33,309
  • 15
  • 79
  • 114
  • 2
    Good point here. Git will add the `.git` folder to track all the repository details. TFS will at a minimum modify your `.sln` (or is it the `.csproj`?) files to put the location of the remote repository into it. – CodingWithSpike May 16 '11 at 13:30
  • 5
    I'd forgotton how much I used to hate how VSS would modify your files 'for' you. – Paddy May 17 '11 at 12:51