版本控制系统

目前，CPython 及其支持的代码仓库使用 Mercurial。作为现代的分布式版本控制系统，自从从 Subversion 迁移以来，它一直为我们提供了良好的服务。但是，在评估 VCS 时，我们必须考虑 VCS 本身的功能以及围绕该 VCS 的社区网络效应和关注度。

实际上只有两个真正的选择：Mercurial 和 Git。这两个系统的技术能力基本相同，因此本 PEP 侧重于它们的社会方面。

无法获得使用特定 VCS 的项目或人员数量的确切数字，但是我们可以通过查看几个信息来源来推断哪些项目正在使用哪些 VCS。

Open Hub（以前称为 Ohloh）统计数据 [1] 显示，Open Hub 索引的代码仓库中，37% 使用 Git（仅次于 Subversion 的 48%），而 Mercurial 仅占 2%，仅高于 Bazaar 的 1%。在 Open Hub 上，Git 的使用量是 Mercurial 的 18 倍多。

另一个关于 VCS 流行度的信息来源是 PyPI 本身。此来源更针对 Python 社区本身，因为它代表为 Python 开发的项目。不幸的是，PyPI 没有表示此信息的标准位置，因此需要手动处理。如果我们将搜索范围限制在 PyPI 上的前 100 个项目（按下载次数排序），我们可以看到其中 62% 使用 Git，22% 使用 Mercurial，13% 使用其他内容。对于 PyPI 上的前 100 个项目，Git 的使用量略低于 Mercurial 的 3 倍。

这些数字支持 Git 作为开源项目中更流行的 DVCS 的轶事证据。选择更流行的 VCS 有许多好处。

对于新贡献者而言，它增加了他们更有可能已经学习了 Git 基础知识作为处理其他项目的一部分的可能性，或者如果他们现在才学习 Git，那么他们将能够利用这些知识并将其应用于其他项目。此外，更大的社区意味着更多的人编写操作指南、回答问题和撰写关于 Git 的文章，这使得新用户更容易找到他们试图学习和使用的工具的答案和信息。鉴于其普及性，也可能会有更多围绕 Git 编写的辅助工具。这增加了从 GUI 客户端、辅助脚本、代码仓库托管等所有内容的选择。

此外，将 Git 作为提议的后端代码仓库格式不会禁止 Mercurial 粉丝使用 Mercurial！Mercurial 用户可以使用 [2] 插件，允许他们使用 Mercurial 前端从 Git 服务器推送和拉取。这是一个维护良好且功能强大的插件，似乎受到 Mercurial 用户的喜爱。

代码仓库托管

CPython 的官方代码仓库在何处以及如何托管在某种程度上取决于 VCS 的选择。对于 Git，有几个选项。事实上，一旦代码仓库托管在 Git 中，分支就可以镜像在许多位置，在许多免费、开放和专有的代码托管站点中。

对于 CPython 来说，采用一个单一的官方代码仓库仍然很重要，并且有一个 Web 前端，允许完全通过 Web 进行许多方便和常见的交互，而无需始终进行本地 VCS 操作。这些交互至少包括带内联注释的代码审查、分支差异、CI 集成和自动合并。

本 PEP 提议采用 [3] 实例，在 python.org 域名内运行，PSF 和 Python 基础设施团队可以访问并最终控制，但由 GitLab, Inc. 捐赠、托管和主要维护。

为什么选择 GitLab？因为它是一个功能齐全的 Git 托管系统，拥有现代的 Web 交互、软件工作流和 CI 集成。GitLab 的社区版 (CE) 是开源软件，因此与 CPython 社区的原则紧密一致。

代码审查

目前，CPython 使用 Rietveld 的自定义分支，该分支修改为不在 Google App Engine 上运行，并且目前实际上只有一人维护。它缺少许多现代代码审查工具中常见的特性。

本 PEP 提议利用 GitLab 内置的合并请求和在线代码审查功能来促进对所有提议更改的审查。

GitLab 合并请求

GitLab 托管项目的正常工作流是提交一个 *合并请求*，要求将功能或错误修复分支合并到目标分支，通常是稳定维护分支之一或新功能的下一个版本的 master 分支。GitLab 的合并请求在形式和功能上类似于 GitHub 的拉取请求，因此任何熟悉后者的人都可以立即使用前者。

提交后，提交者和审阅者之间可以就更改进行讨论。这包括一般评论和附加到源分支和目标分支之间差异特定行的内联评论。还可以配置项目在提交的分支上自动运行持续集成，其结果可以直接从合并请求页面看到。因此，审阅者和提交者都可以立即看到测试结果，从而更容易仅合并通过测试的分支。对源分支的每次新推送（例如，响应评论者的反馈或修复失败的测试）都会导致 CI 的新运行，以便请求的状态始终反映最新的提交。

与旧的“将补丁提交到错误跟踪器”模型相比，合并请求具有相当大的优势。它们允许开发人员使用标准 VCS 工具完全在 VCS 中工作，而无需创建补丁文件或找出将补丁上传到的正确位置。这降低了发送更改以供审查的障碍。

合并请求更容易审查。例如，它们提供漂亮的语法高亮差异，可以以统一或并排视图的形式操作。它们允许在内联和整个合并请求上进行评论，并以一种简洁统一的方式呈现，这也会隐藏不再适用的评论。可以隐藏和显示评论。

如果源分支可以干净地应用到目标分支，则实际合并合并请求非常简单。核心审阅者只需点击“合并”按钮，GitLab 就会自动执行合并。可以选择重新设置源分支的基础，合并完成后，可以自动删除源分支。

GitLab 还提供了一个很好的工作流，用于完全通过其 Web 界面向项目提交拉取请求。这将使 Python 文档在每个页面上都具有“在 GitLab 上编辑”按钮，并且发现错别字、不准确之处或只想改进他们当前正在阅读的文档的人员。他们只需点击该按钮即可获得一个浏览器内编辑器，让他们可以进行更改并从浏览器中提交合并请求。

X 不是用 Python 编写的

当前工具（Mercurial、Rietveld）具有的一个特性是所有部分的主要语言都是用 Python 编写的。本 PEP 更侧重于工作中 *最佳* 的工具，而不是那些碰巧是用 Python 编写的 *最佳* 工具。对于任何开源项目而言，志愿者时间都是最宝贵的资源，我们可以通过关注工具本身的优缺点，而不是其作者碰巧用什么语言编写它们来最好地尊重和利用这些时间。

一个担忧是我们是否能够修改工具以满足我们的需求，然而，这里的一个目标是不要修改软件以满足我们的需求，而是适应更标准化的工作流程。这种标准化带来的好处是可以开箱即用地重用工具，从而释放开发人员的时间，让他们能够真正地专注于 Python 本身，并能够在项目之间共享知识。

但是，如果我们确实需要修改工具，Git 本身主要使用 C 编写，与 CPython 本身相同。它还可以使用任何语言为其编写命令，包括 Python。GitLab 本身主要使用 Ruby 编写，并且由于它是开源软件，因此我们可以向上游社区版提交合并请求，尽管使用的是大多数 Python 程序员可能不熟悉的语言。

Mercurial 比 Git 更好

从技术层面上讲，Mercurial 和 Git 哪一个更好是一个非常主观的意见。本 PEP 没有说明 Git 或 Mercurial 的机制哪个更好，而是关注这两个选项可用的网络效应。虽然本 PEP 建议切换到 Git，但 Mercurial 用户并没有完全被排除在外。通过使用 Mercurial 的 hg-git 扩展，使用服务器端的 Git 仓库非常简单直接。

CPython 工作流过于复杂

之前讨论中出现的一种观点是，CPython 的多分支模型对于 GitLab 样式的合并请求来说过于复杂。本 PEP 不同意这种观点。

目前，任何特定的更改都需要手动为 2.7 和 3.x 创建补丁，在这方面不会有任何改变。

如果有人提交了当前稳定分支（例如 3.5）的修复程序，则可以使用合并请求工作流来创建将当前稳定分支合并到主分支的请求，假设没有合并冲突。与往常一样，合并冲突必须手动并在本地解决。由于开发人员还可以选择在本地执行合并，因此这比当前必须始终在本地执行合并的情况有所改进。

对于必须应用于稳定发布分支的当前开发分支中的修复程序，在许多情况下，可以本地 cherry-pick 并将更改应用于其他分支，并为每个稳定分支提交合并请求。也可以只 cherry-pick 并本地完成合并。所有这些都是使用标准的 Git 命令和技术完成的，其优点是所有此类更改都可以通过审查和 CI 测试工作流进行，即使是合并到稳定分支的更改也是如此。小的更改可以在 GitLab 网页编辑器中轻松完成。

没有任何系统可以隐藏维护多个长期分支所涉及的所有复杂性。工具所能做的只是尽可能轻松地提交和提交更改。