TL;DR: If you want an integrated, enforced process, use TFS. If you value developer freedom and individual work strategies, use git.
The players:
TFS (Team Foundation Server) is Microsoft’s answer to version control. TFS was designed big and bad-ass enough to support development of Visual Studio, like 5 million lines of code. [1] Since not everyone lives in Redmond, TFS tries to minimize network traffic and keep the work on the server.
git is open-source. It was created to manage the source code of the Linux kernel, roughly 15 million lines of code. [2] Development is distributed among thousands of contributors around the world. Many features and versions are in process all the time.
The setting:
DevTeach attendees and speakers provided all the TFS information in this post. Thanks everybody!
Why should your team use one or the other?
First, if you don’t use Visual Studio, forget about TFS.
[Correction: see Wes MacDonald’s comment below. It can be done.]
Second, do you want version control or a full suite including a build server, work item tracking, and analytics? git is version control only. Github has some of the same bells and whistles as TFS, but Github is outside the scope of this post.
[update: TFS has started to embrace git, and you can use git as version control within TFS. If you’ve worked this way and have opinions, please add your comment.]
Here’s a high-level comparison of features, for those who enjoy such formats. Below that, find discussion of the important feature differences, user experiences, and the one question that will tell you which is right for you.
| Feature | TFS | git |
| Save source code | Yes | Yes |
| Retain all version history | Yes | Yes |
| Group changes into sets | Yes (file level only) | Yes |
| Automatic change detection | in 2012 | Yes |
| Branch | Yes (not easy) | Yes (very easy) |
| Merge between related branches | Yes | Yes (very easy) |
| Safe merge between unrelated branches | No | Yes |
| Offline access to history | No | Yes |
| Offline commit | No | Yes |
| Offline commit | No | Yes |
| Sneaky automatic merges on the server | Yes | No |
| Enforce requirements before commit | Yes | No |
| Private local branches | No | Yes |
| Learning curve for users | Low | Medium |
| Learning curve for administrators | Very high | Medium-high |
| GUI support | Strong | Poor |
| Conditional commit (if tests work) | Yes | No |
| Save IDE state | Yes | No |
| Work item tracking | Yes | No |
| Automated builds and tests | Yes | No |
| Analytics and charting | Yes | No |
| Manual test tracking | Yes | No |
| Installation | 1/2 day | 10 minutes |
| Deployment, central and local | days to months | 1 day |
| Free online hosting | Yes | Yes |
| Cost | $$$ | free |
| Security | Yes | No |
What does this chart say? It says, “Git does version control, and does it well” and “TFS does version control and build automation and work item tracking and test tracking and analytics in a SQL Server data cube with graphs and charts.“
TFS is a whole development workflow suite. It integrates all its parts, and then integrates with Visual Studio, Sharepoint, and Active Directory. Git doesn’t impose or supply any of these parts; there are other solutions both open-source and commercial. If you want to select each item of furniture separately, hunting through different stores until you find the best chair and couch and table for you, then git is your source control rug. If you prefer to stop at Ethan Allen and choose a coordinating set, that’s TFS.
Michael’s company uses TFS for source control. On work item tracking, he says, “We haven’t made use of this feature because we haven’t adapted our business process to it… which come to think of it doesn’t make sense.” You don’t have to use all the features of TFS.
Choosing to use all of TFS touches the whole business of producing software. An impact like this can lead to a lot of meetings, and that is why J.R. Roy and James both said deployment can take months, even though installation is fast.
I’ll highlight a few killer features of TFS, and then a few of git.
If you like tight, granular control over security, TFS has this. Use AD groups or define your own; assign read and write permissions down to the individual file level if needed. In contrast, access to whole git repositories is enforced by the file system.
The tight integration of TFS components enforces traceability: for instance, organizations can require that each changeset be associated with a work item. Luc says TFS is “good stuff. All code is related to a work item, everything is linked together.”
TFS has an explicit checkout process. This is both bad and good. In TFS 2010 and earlier, files are read-only until Visual Studio checks them out, which drives people nuts. External editors don’t integrate. In TFS 2012 there’s an improvement: changes are noticed automatically, and the checkout performed behind the scenes. This explicit checkout process is good because when the server knows who is working on each file, a developer can find out who else is changing the file they’re about to slaughter. I’ve wished for this in IntelliJ IDEA with git.
Then again, as Maxime points out, “If you’re working on the kernel of Linux you don’t want to know” whether sixty other developers in fifty different feature branches are working on the same file.
There’s another feature of TFS that will either make you say “fantastic!” or “run away!” TFS requires SQL Server, and it uses the database to store all kinds of tracking data about work items, commits, code quality, and build history. It outputs an entire data cube to generate burndown charts, bugs over time, and all those high-level pictures that give managers the illusion that they know what’s going on in the development team.
Now for git’s killer features. Git is a distributed version control system (DVCS), which means that every developer’s copy can access every version of every file ever, even on an airplane. Incidentally, this serves as a free offline backup for every dev who takes their laptop home. More importantly, people can view history, save their own commits, and branch all without a connection to the central repository. The central depot is accessed only when explicitly requested.
There’s a subtler advantage to having a whole repository locally: saving work is separated from sharing work. Developers can save a series of changes and then test thoroughly before transferring those changes to the central depot and build server. As Tri put it: “I like being able to save my code without making my friends suffer.”
Then again, as Etienne Tremblay sees it, the extra step of saving locally and then sharing “adds a layer of complexity.” It is another step the developer has to think about, another decision to be made.
Good news for the developer who wants the privacy of git while his organization prefers TFS: integration. There’s git tfs, which is a git plugin, and git-tf, written by Microsoft. Git repositories and TFS can talk to each other. Try git without impacting your team.
At this point, git fans are screaming, “What about branching and merging??” The subtleties of the differences here are beyond the scope of this post, but in brief: branches and merges are orders of magnitude smaller and simpler in a git workflow. I create git branches and merge changes several times a day. Contrast with Daniel, a TFS user: “We tried branching one time, but we didn’t end up using it.”
Then again, Etienne points out, “dealing with branches is very complicated for people.” Maybe developers don’t want this alternative.
At its core, TFS is centralized. To reduce network traffic, Microsoft “chose a design where the vast majority of information (including information about your local workspace) was stored on the server.” [1] Git, on the other hand, keeps every local copy fully independent. Even the central depot is only central by convention. The happy rumor is that TFS is embracing more of the distributed model in future releases.
Now for the real, defining difference between TFS and git. TFS says, “This is how to run your process. Follow these steps.” There are customization points; these are a lot of work and will be decreed by the organization. Git says, “it’s your repository, do what you need to do. Then choose how to tell the story of your project.” Git gives you, as a developer and as a team, a lot of choices. That’s not always a good thing.
Howard Dierking provides the one question you need to ask yourself: “Do you want something that’s easier to apply corporate governance to?” If yes, then TFS.
——
[1] http://blogs.msdn.com/b/bharry/archive/2011/08/02/version-control-model-enhancements-in-tfs-11.aspx
[2] http://en.wikipedia.org/wiki/Linux_kernel
While git provides no default governance mechanisms, the pre-commit (local repo) and pre-receive (\”central\” / remote repo) hook mechanisms offer huge flexibility.I've built mechanisms to comply with a previous employer's SAS-70 specified controls. It's quite easy to build something that meets your specific needs including but not limited to:* creating ACLs on files / directories / hierarchies (and if your language has the tools, down to namespace & functions)* rejecting commits based on author, time of day, size, lack of sign-off* gating commits based on testing / integration (automatic or manual) sign-off* rejecting previously blacklisted commits from resurfacing (a good way to implement sometimes necessary purges of HIPAA PHI (or similar) that was accidentally pushed)Naturally there's also ways (such as provided by GitHub) to trigger post-commit events related to process.I know nothing about TFS but, from an engineering process (efficiency, ergonomics, happiness) standpoint find the lack of good branching & merging strategies to be an unforgivable absence in this shiny modern era. That seems a bit hyperbolic but I'll stick to my guns on that …without screaming about it. ;-)I've found that if you have knowledgable release / process engineers, git can become a very precise process tool, yielding exactly what you need, adapting to future needs easily.Separately, Git also has the ability to clone with a shallow history and even span (and join when needed) history across multiple repos (the Linux Kernel does this) with mechanisms like git-replace.I've found that regardless of the version control and configuration management system in use, nothing is a substitute from having solid engineering cycles spent building, maintaining and adapting the tools to fit the process needed (which can change over time and project). One thing tools like git offer are very flexible simples (channeling Rich Hickey and Stu Halloway here) to build whatever you need.
BTW, thank you for another great post, Jess!I would also –amend the above say that there are some aspects of git which are nearly indefensible (much of the UX of the CLI) and git still may not be the right tool for some environments. I do have a problem equating not-offering-stock-process with not-being-able-to-incorporate-(and-enforce)-process. Git's quite able to do be built into whatever process and control mechanisms you need (with some fuzzy exceptions about arbitrarily restricting file/directory/path checkout access to certain access groups).
Thanks for this! Git, in combination with other free stuff and some work, can do just about anything. And it supports intelligent work soooo much better. But you're right about the UI!Git is not for the herd.In all cases, no source control system can make up for what Etienne called 'developer hygeine.'
Great post Jess, I thought I'd comment on a few of your statements.Let me also declare up front I'm a Visual Studio ALM MVP so I have a bias/preference towards Team Foundation Server. \”if you don't use Visual Studio, forget about TFS.\” This is simply not true, Team Explorer Everywhere is available from Microsoft and supports quite a few Operating Systems, IDEs and versions of the JRE. Reference: http://www.microsoft.com/en-us/download/details.aspx?id=4240\”Branching in TFS (Not Easy)\” – I am curious why you don't consider it easy in Team Explorer, Visual Studio 2012 has a new and improved compare and merge tool and if you like you can even plug in your favorite one. Team Explorer also supports branch visualization (introduced in 2010) which enabled you to visualize the branching hierarchy and even track change-sets as they were merged.My favorite quote about branching is \”Don’t create a branch unless you are willing to take care of it. A branch is like a puppy. – Eric SinkIt's ok to be afraid of branches but not so afraid that you never use the feature. This applies to any version control system.\”Safe merge between unrelated branches – No\” – I am assuming you're referring to a baseless merge. This was only available from the command-line in previous versions of VS/TFS in 2012 a baseless merge can be performed in the merge wizard.\”Sneaky automatic merges on the server – Yes\” – It is not automatic or sneaky (you're too funny). TFS will perform the merge automatically for you (provided there are no conflicts) in your local workspace but you must still check-in the changes to TFS.Cheers,@wesmacdonald
I don't understand what the problem Daniel was having with branching. Branching in TFS is very simple. All you do is right click on an existing branch, trunk, or file and select branch. After that you get the dialog that asks you where you want to put it. Then TFS handles the rest for you.
That is a useful question.The problem isn't the creation of the branch, but in keeping the branch up to date with the changes in trunk and in merging changes back into trunk later. These are the parts that make branches a big pain in TFS and in subversion.
I got this automated process control from bernstein distributors, and I'm wondering how I will be able to use it. Do you have suggestions for it?
If that's the case then the problem isn't about the process but rather, it's on the system itself. The best way to avoid any defects in the programs or any products it's always good to make a regular or, if as much as possible, perform a daily check up on the overall system and production of it.
TFS Branching and Merging (mostly the keeping things in sync after a branch) can be difficult if you use it like Git. But it's not Git, so if you use it like TFS, that means things like don't branch when you don't have to (i.e. structuring the solution and planning work in a way that reduces the need for branching), defining a strategy for branching and merging up front, making use of things like shelvesets (the whole Suspend My Work function in 2012 is very powerful and encompasses Work Items and Source code), etc. Yes Git does branching and merging better than TFS so when you work with Git work in a way that takes advantage of that. But when you work in TFS work to it's strengths.
You might want to update the post to reflect http://tfs.visualstudio.com giving you free access (and you can use Git or TFS for source control). It removes the large setup time and prevents you from having to do 90% of the administration work.
We now have full support for git in TFS 2013 and Visual Studio Online (http://visualstudio.com). You don't have to choose between git and TFS – use them together.
Numerous retailers provde the options of shopping for, marketing, booking along with leasing associated with new along with used construction apparatus for you to components services along with repair along with appliance preservation. construction companies san francisco
You will get the same Problems in git as in TFS when you merge things. But it is ways easier to just use TFS and merge things if you got a product where you must support different versions with ways different sources (because it evolved over time). Just a few clicks and you have a new branch. Just a few clicks and you merged some/all or just one changeset, a subset of a changeset or even only one file/folder. This is not to complicated in TFS, you most ensure your developers merge their things in time and not wait a few month and merge than.Worst about git that it is not so well integrated (even in VS2013 are missing some base-functions in the git integration). It just costs much time to do something with git. I've the feeling that I spend more time on git than writing/testing code. I don't want to work with a source control system, I want to do my work.A source control system should be made it easy for developers, so they do spend almost no time with this. Git just isn't there. Everything is just handled way to complicated.
I've used both TFS and git for my work. Now some of you might not agree with me. And probably even curse me for saying this. But TFS makes you slow and inefficient as a developer. Trust me on this one.When I use git. I feel empowered. While on the other side I do not feel same with TFS GUI environment.Now some of you might think security is better in TFS version control system. I would say, don't underestimate security in git.For those of you who are dearly attached to GUI environment and like to click your mouse buttons a lot. Start using command line environment starting from today. For god's sake, you guys are developers. Not some customers, who just like to click buttons on screen.Command line will make you faster and efficient thinker as a developer. Trust me on this one also.
Actually Git does have security. It's one of the primary features! And Git's GUI support is GREAT when you use TortoiseGit.. actually it's far superior than TFS
Git is excellent for local branch but tortoise gui is still premature to do anything. TFS has all the great tools but I felt it was still complicated to use. It felt like lot thrown at you at one time. Tfs with git is a good option of you want to have a flow in your development process including build.
I would like to add my working habit into a reply, maybe other people feel this also: i write code all day long, my usage of VS is mainly with keyboard shortcuts, the mouse is just for browsing the projects. With this in mind, doing a checkin/commit/push or better yet a merge or conflicts resolution with a few clicks, save, and then go-back-to-my-code is heavenly 🙂 and also less time-consuming. What drives me away from git is the whole process of finally committing my code for others to see it. It takes time, and seems to me that to much of it. Add to this the whole writing command lines into bash just seems like my father's style of working on a PC :). I believe that some processes should be automatic so you can focus on your true tasks.What drives me away from git, sadly, also pulls me towards it: that empowerment feeling you get knowing the states and branches of your application, and after you finally get your code merged, you get a feeling of accomplishment. Maybe that's just how i see it, but if this is something you say also, i can resonate with itThis should go into other replies maybe, but: people need to find out that git branching and tfs branching are 2 different concepts for their specific workflows; you cannot compare them, please research having this in mindCheers!