Recognizing the popularity of distributed version control in general and Git in particular, Microsoft today has announced it is now hosting Git on Team Foundation Service. It also announced a preview of a plug-in for Visual Studio 2012 that enables you to work with Git hosted on a Team Foundation Server.

According to Brian Harry, Microsoft technical fellow on the Team Foundation Server team, when a user creates a project on the Team Foundation Service, it will give that user a choice of creating Team Foundation version control or Git version control. “All of our full Web experience will work with the Git version control,” he said. As for the Visual Studio 2012 plug-in, it will work with Git hosted on Team Foundation Server as well as with GitHub or, he said, any other version of Git.

The key piece there is the libgit2 library, which can interface with Git repositories hosted in any service and any platform, just like the Git command-line client does right now. “Git is the back-end repository stuff, and it’s the (Team Foundation Service) ALM workflow over the top of that which makes it a great solution, and we are absolutely building a first-class ALM workflow—team workflow—over top of Git,” said Harry.

Adding to the enterprise features are integrating Git with Active Directory and Identity (so corporate credentials work with the repository), as well as auditing and security, Harry said. “Things like online backup and restore, clustering/high availability, peer replication…we’re bringing things we think will make Git more approachable in the enterprise than it has been to date.”

The effort on Git has been going on for some time now, Harry said. He explained that after Team Foundation Server 2012 was complete, the team began to look at patterns and trends in the industry as they relate to modern application development, with its device-connected cloud applications and distributed teams creating applications that are small, loosely coupled components stitched together. And they found a groundswell of interest in distributed version control.

“When we chose to go the route of Git, one of the things that was clear was that that path involved deep involvement with the OSS community,” Harry said. “Git has come a long way in the OSS community. It’s got a lot of passion there and a lot of people who contributed to it. This choice was really a choice to step away from a proprietary path and go with an OSS path, and that means not only consuming and providing the open source, but actively contributing to the Git community. We have been—for the past, I’d say, close to six months—very active in the Git community.”

Microsoft, Harry admitted, tried to fly under the radar in the Git community at first, until the company was ready to discuss its plans, but, he said, “The GitHub guys figured it out fast. They saw us contributing a bunch and were a little surprised and wanted to know what we were doing, so we chatted with them a bit about it.” That led to a collaborative effort to bring Git forward on Windows and in Visual Studio. The goal for Microsoft was to make Git “really work in the enterprise,” he said.
#!
Vicent Martí, who works at GitHub and maintains the libgit2 library, said of Microsoft’s efforts: “Microsoft has been embracing more and more open source lately, especially regarding developer tools. In this specific instance (version control), Microsoft has traditionally invested on centralized proprietary version control, but it’s rather obvious to me that when it comes to distributed version control, Git has won the battle and there’s no contest about it. Microsoft seems to believe that too, and I think it’s a great thing that Redmond is currently willing to bet on a winning horse, even if it’s open source.”

Martí went on to add that the work with Microsoft on libgit2 was critical to making Git “a native citizen in the Windows world.”

The work in the Git community continues Microsoft’s move down the open-source path. “In TFS, we offered an Eclipse/Java solution,” said Harry. “It’s been three years or so since we introduced that and really began our efforts to embrace the open-source community, doing Jenkins integration and all of that.

“This is to some degree kind of the next step on that path. At least within the Developer Division, it’s been one of the biggest and most high-profile efforts to really go out and engage with and contribute to an existing open-source project kind of as peers in a fully participatory way. There’s been some learning for us there as we’ve gone through that, but so far I think we’ve had a really good relationship with the other contributors on the project, and it’s been good for us, and I hope good for them.”

What is libgit2?
As Martí explained: “libgit2 is a rather ambitious open-source project we’ve had at GitHub for over two years now. The goal is to re-implement all Git functionality in the shape of a re-entrant C library in a natively cross-platform manner and with proper error handling. We currently use libgit2 in our desktop clients (GitHub for Windows and GitHub for Mac) and in our back-end architecture for GitHub.com and Gist.

“Microsoft joined the project pretty late on in its development, but their contributions have been critical to making libgit2 as complete and powerful as it is now, especially when it comes to Windows support. We’ve always had Windows on mind while developing the library (it’s the only Git implementation that runs natively on top of the Windows API), but thanks to Microsoft’s support, libgit2 —and hence Git—now feels like a true native citizen in the Windows world.

“There was a lot of additional work required to make libgit2 (a C library) [interoperable] with the .NET world, but this is a task we undertook long ago: libgit2sharp are the open-source .NET and Mono bindings for libgit2, carefully maintained by Emeric Fermas (a good friend, but not a GitHub employee). We were already using libgit2sharp to power GitHub for Windows, our Windows client written in C#, but Microsoft’s help on brushing up the bindings has been very welcome.”