Git vs Team Foundation Server

Question

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

[git] Git vs Team Foundation Server

Examples related to git

Examples related to tfs

Examples related to tfvc