In my Visual Studio 2013 post from TechEd a couple of weeks ago, I made a very innocuous comment about including Git support in our TFS 2013 preview that will ship next week (at the Build conference).  I wanted to take a few minutes to expand upon it. We first introduced Git support as a VS 2012 VSIX for Visual Studio and server side support in Team Foundation Service in Feb 2013. Since then, we’ve been updating both regularly – every 3-6 weeks.  At the announcement, I also said that Git support would be “included in the next major release”.  At the time, I couldn’t say more about what that next major release would be but you now know it is Visual Studio 2013 and Team Foundation Server 2013 – to be released before the end of this year and with a “go-live” preview releasing next week at Build. That preview will include both integrated Visual Studio tooling that works both against our Git server implementation and others, and a Git server integrated into the on premises version of TFS. The Visual Studio tooling will be an evolution of what you’ve already experienced with the VS 2012 VSIX – with the latest improvements. But I wanted to spend a bit of time talking about our Git server support since you really haven’t seen that yet. When we made the decision to support Git in TFS, it was in the context of wanting to provide the best distributed version control experience for developers along with the best centralized version control experience. In both cases, we aspire to provide the capabilities in a way that fits enterprise needs for security, auditing, management, reliability, etc. This is an area where Git has historically had some weaknesses and a poor reputation. So, as we set out to add Git support to TFS we set out to do it as an “enterprise grade distributed version control system”.  At the same time, it was important to us to “stay true to Git” by ensuring that our implementation is 100% Git compatible – supporting the full set of Git features and compatible with any Git client. We have tried to do this by providing a set of additional capabilities and control on the service while allowing the distributed clients to have “full freedom” to do with GIt as they choose. This gives administrators the ability to provide some control over the central server while not imposing constraints on what developers can do with their local repos. As with Git, in general, we are on a journey and not everything I’m going to talk about here is 100% done but much of it will be in TFS 2013 and the rest should appear in Updates to TFS 2013. So let’s get concrete about it: Ease of installation – We’ve now made installing Git a seamless part of installing TFS. There’s nothing to go and track down and download. Nothing to install and configure separately. You just install TFS 2013 and automatically get Git support. Support and servicing – Because we are shipping it, we support it. This means if you have any problem, you can contact our support and get help. You will receive security updates, hot fixes, regular Updates and more all the same way you are used to getting them. We’ll work hard to make sure your TFS Server is healthy and up to date regardless of which features you are using. High availability – Since early on, we’ve worked to make TFS support high availability.  Our Git support is no exception – we support all the same things you are used to with TFS – load balancing and clustering to ensure that your server will continue to run in spite of hardware and software failures, Geo-replication if you need to be certain that you maintain business continuity even in the face of regional outages, online backup and restore as an integrated part of TFS so that your existing enterprise grade backup and restore policies (full, incremental and transaction log) will continue to work (giving you good RTO and RPO). Scale – Like with TFS, you can scale your TFS installation seamlessly as your needs grow. This includes scaling out both the application tier and the storage tier as you need to add additional capacity. Ease of management – Our Git implementation is fully integrated in to TFS so that all of your management policies can continue unchanged – service account management, hardware migration, software patching, backup & restore, monitoring, permission management and more. Integrated Authentication – Our GIt support fully integrates Windows Active Directory authentication so that all of your access control, auditing, etc can be done against a consistent and manageable infrastructure. As part of this, all changes are audited against an authorized identity assuring you know who made each change. Enhanced permissions – We’ve built (and are building) a bunch of additional repository and permission management capabilities that allow administrators to “control the chaos”. The first set include the ability to manage repositories (create, delete, rename, etc) and repository level permissions that control Read, Write and Administer permissions. We also include a 4^th permission that addresses a key issue many customers have had with Git – “Force push”, which effectively enables users to “alter history”.  While we enable this ability, we also enable administrators to disable it with a permission.  We are also working on additional permissions now – like branch level permissions that will enable administrators to control who can create, delete and use individual branches.  In this way, developers can use branching any way they choose locally but, when they are going to push back to the master repo, they are constrained by policies the administrator configures. ALM integration – And, of course, we are fully integrating Git into the TFS ALM workflows – work item tracking, build automation, reporting, code review, and more. Not all of that integration is complete yet but we’ll be fleshing it out through the 2013 Updates and, when we are done, we should have full parity on ALM integration capabilities between Team Foundation Version Control and Git Version Control. Localization – Like the rest of our product, our Git capabilities will be localized into the same languages as the rest of VS making it more approachable by parts of the non-English speaking world.   All in all, we believe that when you combine this “enterprise capability” on the server side along with the ease of use that comes with VS integration on the client side, you get the first distributed version control system really ready for broader adoption in the enterprise. And, I must stress for all those that will be worried that we’ll somehow contort Git, it is and will be a 100% compatible Git implementation with all the capabilities and speed you’ve come to know and love about Git. I encourage you to download the preview next week and try it out. Thanks,

Brian