幸运的是，我将在今年晚些时候写一些关于FreeBSD转向GIT的博客。今天，我们将从为什么要开始？
推动这一变化的因素有很多。我们将探索原因，从Subversion的长期可行性，到对工具的更广泛支持，这些工具将使项目变得更好。今天我将列举这些要点。关于这一决定是如何做出的，有一些后勤方面的观点。不过，关于我们是如何走到这一步的，我不会涉及政治问题。虽然喜欢争论和吹毛求疵的内部人士很感兴趣，但它们与更大的社区并不比今天早上将食品送到杂货店的送货卡车的颜色更相关(即使它的最新一集是一只酷酷、斗志旺盛的卡通猫，它通过在这家商店购买食物来追求自己一生的挚爱，这只猫参与了多年的弧线活动)。
Apache Foundation曾经是Subversion的照顾者和主要用户。他们所有的报道都使用颠覆。虽然从技术上讲，他们仍然是颠覆的守护者，但他们已经将所有的存储库都转移到了GIT。这是一个令人担忧的发展，因为可预见的结果将是较少的颠覆性开发。这意味着如果我们长期使用FreeBSD项目，它将需要承诺支持Subversion。FreeBSD现在是最后一个使用Subversion的大型开源项目。LLVM最近完成了向GIT的过渡。人们对颠覆生态系统的健康和生存能力有非常真实的担忧，特别是与蓬勃发展、充满活力的GIT生态系统相比。
与Subversion相比，Git对较新的CI工具有更多的支持。这将允许我们，一旦事情被完全分阶段实施，就可以提高进入树的代码的质量，同时大大减少构建中断和意外的倒退。虽然可以在GIT之外使用CI工具，但是集成到GIT工作流中对开发人员来说需要较少的约束，这使得他们可以在影响其他人之前轻松地修复CI在提交/合并过程中发现的问题。
GIT合并功能比Subversion要好得多。您还可以更容易地管理补丁，因为git支持重新设置基数的工作流。这使得更干净的补丁成为较大提交的逻辑位。Subversion不能做到这一点。
Git还允许通过Git子树合并将多个GIT存储库与子树重写相集成。这样可以更容易地跟踪上游项目，并使我们能够改进供应商导入工作流程。
Git可以很容易、很强健地被镜像。Subversion是可以镜像的，但是这种镜像远远不够健壮。GIT迁移中的障碍之一是，不同的SVN镜像与主Repo或彼此具有不同的数据。Git中的镜像已内置于工作流中。因为每个回购都是克隆的，所以镜像是免费的。还有很多第三方镜像网站可用，比如GitHub、GitLab和SourceForge。这些站点还提供协作和配置项附加功能。
Git可以签署标记和提交。Subversion不能。通过这些措施，我们可以增加真理来源的完整性。
镜像还可以打开更多的第三方插件。在自动化测试和持续集成方面，GitLab可以做一些事情，Github还可以做其他事情。可以在推送分支时运行测试。这两个平台也都有重要的协作工具，它们将支持团队开始为FreeBSD创建新功能。虽然人们可以在有限的程度上使用这些东西，Subversion镜像到GitHub，但如果不转换到GIT，这些工具的全部功能是不可能完全实现的。(=。
这些站点上或独立配置中提供的各种工具将允许我们在许多不同的平台上运行提交前检查和长期提交后测试。这将允许项目利用现有的基础设施，在财务上有意义的地方让其他人运行测试，同时仍然允许项目保留对我们运营至关重要的BIT的控制。
作为一个项目，我们一直在努力解决的一个领域是补丁集成。我们没有明确的方式提交补丁，以便及时采取行动，或者至少这是批评。我们确实有方法，但它们在将补丁集成到树中时只有部分有效。各种类型的拉请求提供了一种接受补丁的集中方式，并且有工具来检查它们。这应该会降低提交补丁程序的人员之间的摩擦，并使开发人员更容易审查补丁程序。其他项目报告说，当迁移到git时，补丁流量增加了。这也可以与开发人员查看补丁之前的自动测试和其他验证相结合，这解决了过去系统的一个大问题：非常低的信噪比。虽然不是灵丹妙药，但它将使事情变得更好，并更广泛地利用稀缺的开发人员时间。
有人说，严格地说，GIT不是一个纯粹的源代码管理系统。它确实是一个也支持版本控制的协作工具。这可能听起来像是敲打git，但实际上它是git最强大的力量。Git的分布式模型允许更轻松、更频繁的协作。整个网站都是围绕这一概念建立的，展示了轻松协作的力量，可以扩大努力和建立社区。
所有这些都是在关于今天的孩子只知道git，但需要学习颠覆的技能集争论之前。这一直是摩擦的一个来源。这一论点得到了人们抱怨必须学习颠覆、教授不得不花时间教授等轶事证据的支持。此外，该行业的研究表明，人们正在从其他选择中迁移到GIT。Git现在的市场占有率在80%到90%之间，这取决于你查看的数据。它被如此广泛地使用，以至于我们不使用它对新的开发人员来说是一个摩擦的来源。
该项目中越来越多的活跃开发人员将git用于其全部或部分开发工作。这导致了少量的摩擦，因为所有这些方式都没有标准化，在将更改推向颠覆时会出现拟合和完成问题，并造成摩擦。他们为这些开发人员提供的生产力的提高在一定程度上抵消了这种摩擦。他们的想法是，将git作为真相的来源，将进一步释放git提高生产率的潜力。
首先，Git不支持实现$FreeBSD$的关键字扩展。虽然人们可以对做这类事情的GIT插件吹毛求疵，但添加的信息并不像Subversion那么有用。这将是一种损失。然而，带标签的关键字扩展已经过时很长一段时间了。过去，源代码控制系统会将提交历史嵌入到已提交的文件中，当它们导入到其他项目中时，只会发现发生了一些奇怪的事情，因此这种做法就会枯萎。几年前，我们用$ID$遇到了类似的问题，所有的项目都换成了$FooBSD$。当源代码跟踪很弱，公司随机导入版本时，这很有用：它会告诉我们有哪些版本。现在，公司倾向于使用GIT来实现这一点，因为GIT可以更好地跟踪源代码功能。这个值不是零，但它比我们在90年代采用它时要低得多。Git也不支持很好地处理它引起的所有合并冲突。由于该工具奖励以更恰当的方式进口的人，似乎更多的公司正在以这种方式使用它，从而减少了对显式来源标记的需求。[编辑：有些人根本不认为这是一种损失]。
其次，Git没有运行的提交计数。人们可以用很多方法来解决这个问题，但是没有一种基本的方法可以像Subversion一样可靠地用作提交号。即便如此，变通方法已足够满足大多数用途，而且许多项目今天都成功地使用了GIT和提交计数。
第三，BSDL GIT客户端远不如GPL客户端成熟。直到最近，还没有可以导入到树中的C客户端。虽然人们可能会争论这是不是一个好主意，但在基础系统中拥有你所需的一切是一个强大的文化传统，很难置之不理。OpenBSD最近编写了GET，它有一个令人愉快的许可(但无论好坏，命令行界面完全不同)。它有自己的问题，这些问题在这里并不相关，但正在很好地成熟。即使有目前的限制，它也是可用的。由于大量的OpenBSDism被烘焙(有些是必要的，有些是免费的)，所以有一个GOT到FreeBSD的活动端口。OpenBSD人员对拥有可移植版本的GET持开放态度，因此这是令人鼓舞的。
最后，改变是艰难的。和你昨天一样，用同样的工具、同样的工作流程和同样的人一起使用同样的工具是很容易的。学习一种新的系统是困难的。将一个工作流迁移到另一个工作流是很棘手的。您必须在积累的知识和工具收益与迁移到新产品所需的成本之间进行权衡。Git迁移团队将从Subversion迁移到Git视为改进和完善FreeBSD工作流程的第一步。因此，我们试图创建一个老用户和开发人员都熟悉的GIT工作流，同时允许在未来进行进一步的创新。
虽然这并不是没有风险和工程上的权衡，但大量证据有力地表明，转向GIT将提高我们的生产力，提高项目参与度，壮大社区，提高质量，最终产生一个更好的系统。它将给我们一个平台，我们还可以重新设计项目的其他方面。这将以重新装备我们的发布过程、我们的源代码分发基础设施和需要学习新工具的开发人员为代价。成本将是值得的，因为它将在未来几年内产生红利。