Recently I moved on gitHub (I’m here), and the first obvious question from my friends which I came across, was what is the big deal about giHub or git?
I had few vague answers but thought to google it out and write a summary. Fortunately, I got a good discussion on stackoverflow (http://stackoverflow.com/questions/4415127/git-vs-team-foundation-server), and below I am copy-pasting few good lines from it.
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.
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.