Today at the ALM Summit I made a bunch of announcements. A couple of them warrant a bit of extra comment 
Today, I made 2 announcements involving TFS, VS and Git.
- Team Foundation Server will host Git repositories – and more concretely, Team Foundation Service has support for hosting Git repositories starting today.
- Visual Studio will have Git support – and concretely, we released a CTP of a VSIX plugin for the Visual Studio 2012 Update 2 CTP today.
Resources
- You can get a good overview of how to get started (including all the download links) by reading this tutorial.
- Watch this video for a 10 minute walk-through.
- Also you can read the news and the Learn content on the Team Foundation Service welcome portal.
That’s right, TFS & VS support a full fidelity implementation of Git. Although this comes as kind of an abrupt announcement, it’s been a long time in the making. We started talking about having DVCS support for TFS a year or more ago. I even mentioned at the end of this post over a year ago that DVCS was in our future. After a few months of investigation (in the middle of working on TFS 2012), we concluded that adding Git support was the right approach. As I write this, I’m wondering what the reaction among our customers will be but I can say the reaction inside my own team when we first proposed this was quite mixed. There were certainly plenty of people who wanted to “build a better DVCS system” or integrate DVCS workflows into the existing implementation. There were others who were concerned about open source and lack of “control” issues. But, the more we looked at it, the more it looked like the right thing to do.
This post is going to be a bit of a weird post. I’m going to structure it as a bit of a Q&A to address many of the questions that came up for us and I’m guess some that will come up for readers. I suspect this post is going to be the beginning of a conversation. I’m going to be doing a Reddit Ask Me Anything session on Friday if you want to come along and chat about it.
Why are we adding DVCS to TFS?
Centralized version control is going to be around for a long time. It’s a model that still works for a very large number of customers and we’re very happy with the solution we have. However, DVCS, starting with roots in the OSS community, has grown steadily in popularity. Some of its benefits fit well with the trends we see in software development: loosely coupled systems, distributed teams, lots of component reuse, incorporation of OSS, etc. Our customers need DVCS workflows integrated with their full ALM process – in fact, it’s one of our top UserVoice requests. I like to say our goal is to have the best available centralized version control solution and the best available distributed version control solution.
Why are we incorporating Git?
When we made the decision that we were going to take the DVCS plunge, we looked at many options. Should we build something? Buy something? Adopt OSS? We looked at Git, Mercurial and others. It didn’t take long to realize that Git was quickly taking over the DVCS space and, in fact, is virtually synonymous with DVCS. We thought hard about building something. Git hasn’t been as friendly for Windows developers as on other platforms. By building on Git, we can take all the time we might spend just “catching up” and spend that effort on something where we can add more distinctive value. Choosing Git just made sense.
Does this mean Team Foundation Version Control (TFVC) is dead?
Not for a second. We still believe that TFVC is the best centralized version control system available. If you haven’t taken a look at version control in TFS 2012 yet you should. We improved it significantly with local workspaces for better offline and lower overhead, a better merging experience, and we’ve been doing a lot of work in the web experiences for version control over the past few months (that affect both TFVC and Git projects). There is still a very important role for centralized version control to play and we plan to continue to carry it forward. Rather than dilute both into a single solution we’re giving you the choice of which workflow is best for your circumstances. However, circumstances change and you are going to want to be able to move code from one workflow to the other and we’re going to help there. Last summer we released a tool called Git-TF which allows you to hook Git up to TFVC and exchange code and we’ll be doing more to improve this area.
But isn’t Microsoft against open source?
Absolutely not. Speaking for my little world, we’ve been engaged with the OSS developer community for years. In my own area, we dabbled (and in some cases made missteps) as we’ve learned our way. OSS became a major part of my world a few years ago when we acquired Teamprise (now known as Team Explorer Everywhere or TEE). TEE is an Eclipse plug-in that gave us a lot more experience in the OSS world. Eclipse is, of course, OSS but so are large chunks of our plug-in implementation. Our engagement with OSS has gradually increased over the years both as we created our own OSS projects (like Git-TF) and engaged in existing ones with small contributions.
All that said, this is a pretty big milestone for us. This is certainly the first time that my team has engaged so deeply in an existing OSS project. Our Git implementation is based on LibGit2 and related projects. We started contributing to LibGit2 a few months ago and have been very active. If you are curious, checkout contributions by Ed Thomson (ethomson), Philip Kelly (phkelley), Jameson Miller (jamill), Congyi Wu (congyiwu) and Martin Woodward (martinwoodward) on the LibGit2 GitHub project. The GitHub team also relies heavily on LibGIt2 and are major contributors. Before we even started coding we spoke with the folks there to make sure they were open to our participation. We have been open with them about our plans and agreed that it made sense for us to work together to bring Git forward – particularly with respect to making it great for Windows and VS. I have to say that the welcome by the entire LibGit2 community has been phenomenal. They have been incredibly helpful as we’ve begun to contribute to LibGit2 and we wouldn’t be in the position we are today without them.
Does VS’s Git integration only work with our Git server?
Absolutely not! Both client and server are standard implementations of Git. Our client will work with pretty much any Git repository – local, enterprise, Codeplex, GitHub, BitBucket, …. And TFS will work with pretty much any Git client – existing Git command lines, XCode, Eclipse’s Git support, …. This was a core principle from day 1. This is not about lock in – it’s about providing a good and interoperable Git capability.
So is there anything special about our solution?
We like to think so. While both client and server are completely standard implementations, we are doing a lot of work to make our implementation as good as it can possibly be. First of all, we are doing deep integration with our ALM tools. Our intent is to provide the same level of integration as we have with TFVC – work item association, change tracking, build automation, My work, Code review, testing, … TFS will give you the best all-up ALM solution with Git as the source control system. We are also working to make sure that our Git server is enterprise class – a common concern with Git historically. We are doing work on auditing, access control, high availability, online backup, etc. All the things that an enterprise is going to be particularly concerned about. And we are working hard to deliver an excellent Git experience in VS. Git can be, um, esoteric. We’ve been working to codify the standard “best practices” for Git in the community to make Git approachable and easy to use by everyone while not sacrificing the power.
When is this shipping?
“This” has many piece so let’s talk about each one in turn:
- Team Foundation Service– As of today you can host Git repos in TFService projects. It is “shipping” now and ready for use. We still have lots more capabilities to add but it’s ready to use for real.
- Team Foundation Server– Our plan is to include Git support in the next major release of TFS. No date has yet been announced.
- Visual Studio 2012 support– We provided a VSIX today. It is a “community technology preview” of the Git VSIX on top of a “community technology preview” of VS 2012 Update 2 (VS2012.2). We’re very pleased with the performance/stability of it but it is not yet officially “go-live”. You are welcome to try it out but it is a preview release for evaluation, so be aware that there may be issues. We’ll be releasing updates about every 3 weeks and you should expect it to converge fairly quickly. I don’t know at this time when it will “RTM” but I expect it to have a “go-live” designation before too long.
- Visual Studio V.Next– Our Git plugin will be integrated into all editions of Visual Studio V.Next (including Express) and will appear in the various pre-releases and RTM.
- Older versions of VS & TFS– At this time, we are not planning to include Git integration in older versions of VS or TFS.
It’s been no small feat getting here – the team has put in a lot of long hours over the past few months. And this is just the beginning of the journey. We’re nowhere near done with our Git solution. We are currently lacking major features – like pull requests – but they are coming. You should continue to see improvements on a regular basis for the foreseeable future.
As always I’m happy to answer questions and enjoy feedback.
Brian