版本控制系统

目前，CPython 及其支持存储库使用 Mercurial。作为一种现代的分布式版本控制系统，自从从 Subversion 迁移以来，它一直服务良好。然而，在评估 VCS 时，我们必须考虑 VCS 本身的能力以及围绕该 VCS 的社区的网络效应和思维份额。

实际上只有两种选择：Mercurial 和 Git。两者的技术能力在很大程度上是等效的，因此本 PEP 侧重于它们的社会方面。

无法获得特定 VCS 使用项目或用户确切数量的数字，但我们可以通过查看项目使用 VCS 的几种信息来源来推断。

Open Hub（以前称为 Ohloh）的统计数据 [1] 显示，Open Hub 索引的存储库中有 37% 使用 Git（仅次于 48% 的 Subversion），而 Mercurial 仅占 2%，仅高于 1% 的 Bazaar。这使得 Git 在 Open Hub 上的受欢迎程度是 Mercurial 的 18 倍以上。

另一个关于 VCS 流行度信息来源是 PyPI 本身。这个来源更侧重于 Python 社区本身，因为它代表了为 Python 开发的项目。不幸的是，PyPI 没有一个标准的位置来表示此信息，因此需要手动处理。如果我们搜索 PyPI 上的前 100 个项目（按下载量排序），我们可以看到其中 62% 使用 Git，22% 使用 Mercurial，13% 使用其他。这使得 Git 在 PyPI 的前 100 个项目中比 Mercurial 受欢迎程度高出近 3 倍。

这些数字支持了 Git 作为开源项目更受欢迎的 DVCS 的传闻证据。选择更受欢迎的 VCS 有许多积极的好处。

对于新贡献者来说，这增加了他们作为参与其他项目的一部分已经学会 Git 基本知识的可能性，或者如果他们现在才学习 Git，那么他们可以将这些知识应用到其他项目中。此外，更大的社区意味着更多的人撰写指南、回答问题以及撰写关于 Git 的文章，这使得新用户更容易找到他们试图学习和使用的工具的答案和信息。鉴于其受欢迎程度，可能还会有更多围绕 Git 的辅助工具。这增加了从 GUI 客户端、辅助脚本、存储库托管等各个方面的选择。

此外，采用 Git 作为提议的后端存储库格式并不禁止 Mercurial 的粉丝使用！Mercurial 用户拥有 [2] 插件，允许他们使用 Mercurial 前端与 Git 服务器进行推送和拉取。这是一个维护良好且功能强大的插件，似乎深受 Mercurial 用户喜爱。

存储库托管

CPython 官方存储库的托管地点和方式在某种程度上取决于 VCS 的选择。使用 Git 有几种选择。事实上，一旦存储库托管在 Git 中，分支就可以在许多免费、开放和专有的代码托管站点中进行镜像。

CPython 采用一个单一的官方存储库仍然很重要，该存储库拥有一个 Web 前端，允许通过 Web 进行许多方便和常见的交互，而无需始终需要本地 VCS 操作。这些交互至少包括代码审查（带内联评论）、分支差异、CI 集成和自动合并。

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

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

代码审查

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

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

GitLab 合并请求

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

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

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

合并请求更易于审查。例如，它们提供漂亮的语法高亮 diff，可以以统一或并排视图运行。它们允许对合并请求本身和内联进行评论，并以统一的方式呈现，还可以隐藏不再适用的评论。评论可以隐藏和显示。

如果源分支能够干净地应用到目标分支，那么实际合并合并请求非常简单。核心审查者只需按下“合并”按钮，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）的修复，合并请求工作流可以用来创建一个请求，将当前稳定分支合并到 master 分支，假设没有合并冲突。一如既往，合并冲突必须手动本地解决。由于开发人员也*可以选择*在本地执行合并，这比当前必须始终在本地进行合并的情况有所改进。

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

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