Git与VS相集成
[原文发表地址] Git init VS
[原文发表时间] 2013-01-30 5:15 PM
今天在 ALM 峰会上，我做出了一连串的声明。其中几个需要一点额外的说明
今天，我的2个公布涉及到了 TFS、 VS 和 Git。
- Team Foundation Server 将托管 Git存储库— —更具体地说，Team Foundation Service从今天开始已支持托管Git 存储库。
- Visual Studio 将拥有Git支持 — —具体而言，现在，我们为Visual Studio 2012 Update 2 CTP发布了一个VSIX 插件的CTP版。
资源
是的 ，TFS & VS 完全支持Git 的执行。虽然这是个突然的宣布，但它已经酝酿很长一段时间。我们在一年前左右或更早时开始谈论为TFS拥有DVCS支持。一年多前，我甚至在此篇文章末尾提到， DVCS是我们的未来。在经过几个月的调查后 （在 TFS 2012 的中间时间段），我们得出结论：添加 Git 支持是正确的做法。当我在写此文时，我很想知道我们的客户将会有什么样的反应，但我可以说，当我们首次提出时，我自己的团队里面的反应是相当混杂的。当然有很多人想要"建立一个更好的DVCS 系统"或将DVCS工作流集成到现有的执行中。还有人担心开放源码，缺少"控制"问题。但是，随着我们深入查看，它看上去越像正确的事情。
这篇文章将会是篇有点怪的博文。我将以Q&A的结构排版来回答我们遇到的很多问题。我认为这篇文章将会是对话的开篇。
我们为什么要添加DVCS到 TFS中？
集中式的版本控制将在很长时间内继续存在。它是一个模式，仍适用于非常大量的客户，我们对我们的解决方案非常满意。但是，DVCS植根于开放源码软件社区，越来越受欢迎。它的一些优势十分符合我们在软件开发中看到的趋势： 松散耦合的系统、 分布式的团队，许多组件的重用、开放源码软件的纳入等。我们的客户需要DVCS工作流与他们的完整的 ALM 进程相集成 — — 事实上，这是在 UserVoice 网站上呼声最高的请求之一。我想说我们的目标是要有最好的集中式版本控制解决方案和最佳的分布式版本控制解决方案。
为什么我们要纳入Git ？
当我们决定我们要采取DVCS时，我们查看了很多选项。我们应该建立一些东西吗？要买东西吗？采用开放源码软件吗？我们查看了 Git、Mercurial等。没过多久就意识到 Git 正在快速接管DVCS空间，其实，几乎等同于DVCS。我们认为构建一些东西很困难。对于Windows 开发人员来说，Git 没有其他平台友好。通过构建于 Git之上，我们可以将所有我们可能的时间花费在只是"追赶"和花一些努力在我们可以在其中添加更多与众不同的价值。选择 Git 行得通。
这是否意味着Team Foundation Version Control （ TFVC ）死了？
绝不是的。我们仍然认为TFVC是最好的集中式版本控制系统。如果你还没有在 TFS 2012 中查看这一版本控制，你应该去看看。我们使用本地工作区大大地改进了它来更好地脱机使用，我们在过去的几个月为版本控制的 web 体验做了大量的工作（影响TFVC和 Git 项目)。集中式的版本控制仍然发挥着非常重要的作用，我们打算继续发扬它。而不是都纳入一个单个的解决方案，我们将让你选择最适合你的情况的工作流。然而，当情况发生变化时，你将能够将代码从一个工作流移到另一个，我们将在那里提供帮助。去年夏天我们发布了一种称为Git-TF的工具，使你能够将 Git 挂钩到TFVC和交换代码，我们将做更多的工作来改善这一领域。
但微软不反对开放源代码吗？
绝对不会。就我小小的世界来说，我们已经与开放源码软件开发人员社区从事多年。几年前，当我们获得 Teamprise （现在称为Team Explorer Everywhere或TEE）时，开放源码软件成为了我的世界的一个重大部分。TEE是 Eclipse 的一个插件，给了我们很多开放源码软件世界中的经验。随着我们创建自己的开放源码软件项目 (如 Git-TF) 以及提交现有的东西，我们与开放源码软件的接触逐渐上升。
都说这对我们来说是一个相当大的里程碑。这是我的团队首次这么深入从事现有的开放源码软件项目。我们 Git 的实现是基于LibGit2和相关的项目。几个月前，我们开始提交东西到LibGit2上，而且大家一直十分活跃。如果你对此好奇，请签出以下人的提交：Ed Thomson (ethomson), Philip Kelly (phkelley), Jameson Miller (jamill), Congyi Wu (congyiwu) 和 Martin Woodward (martinwoodward)。GitHub 团队也很大程度上依赖于 LibGIt2，是主要的提交人。在我们开始编码之前，我们与大家交谈来确保他们开放给我们参与。我们已经与他们就我们的计划交流了，并赞同共同努力让 Git 向前发展是很有意义的 — — 特别是让 Windows 和 VS 更强大。我必须说，整个LibGit2 社区非常受欢迎。我们已经开始为 LibGit2提交东西，他们大大地帮助了我们，没有他们，我们就不会在今天到达这个位置。
VS 的 Git集成只能与我们的 Git 服务器使用吗？
绝对不会 ！客户端和服务器都是Git 的标准执行。我们的客户端将能与任何 Git 存储库使用 — —本地的、 企业的，Codeplex，GitHub，BitBucket，......TFS 将适用于任何 Git 客户端 — — 现有的Git 命令行，XCode，Eclipse 的 Git 支持，......
这对我们的解决方案有什么特别的吗？
我们认为是的。虽然客户端和服务器都完全是标准的执行，我们正在做大量的工作来让我们的执行尽可能地好。首先，我们正在做与 ALM 工具的深度集成。我们的目的是提供与TFVC相同级别的集成 — — 工作项关联，更改跟踪、 生成自动化，My work，代码审查，测试，......TFS 将给你最好的ALM 解决方案，而 Git 作为源代码管理系统。我们也正在努力确保我们的 Git 服务器是企业类别的— — 从历史上看，这是对Git 的共同关注点。我们正在做有关审计、 访问控制、 高度可用性、 联机备份等工作。特别关注企业的所有事情。我们正在努力在 VS 中提供绝佳的 Git 体验。Git 是深奥的。我们一直在为Git整理标准的"最佳做法"，以便让 Git供每个人方便使用。
何时推出它？
"它"包含许多部分，让我们反过来一个一个地讲：
- Team Foundation Service — — 今天你可以托管 Git 存储库在TFService项目中。它已可供使用了。我们仍然会有更多的功能来添加，但真的可以使用了。
- Team Foundation Server — — 我们的计划是在下一个TFS重大版本中包括 Git支持。日期尚未被公布。
- Visual Studio 2012 支持— — 我们今天提供了一个 VSIX。它是VS 2012 Update 2 （VS2012.2） CTP的Git VSIX CTP版。我们非常高兴的是它的性能和稳定，但它还未正式"投入产品使用"。欢迎你试用它，但它只是用于评估的预览版本，因此，请注意可能会出现问题。我们将大约每 3 周发布更新，你应该希望快速聚合。我不知道它什么时候将"RTM"，但我预计不会太久会有一个"投入产品使用"。
- Visual Studio V.Next — — 我们 的Git 插件将集成到 Visual Studio V.Next （包括Express版） 的所有版本中，并将出现在各种预发布版本和 RTM中。
- VS & TFS的旧版本— —此刻，我们不打算在VS 或 TFS 的旧版本中包括 Git 集成。
实现此是个不小的壮举 — — 在过去的几个月里，团队已投入了很多的时间。这只是旅程的开始。我们已经完成了我们的 Git 解决方案。我们目前缺乏主要的功能 — — 像发送请求 — — 但未来会实现。你可以在未来继续定期地查看改进。
一如既往地，我很乐意回答问题，并喜欢你们的反馈。
Brian