《使用 Git 进行版本控制》第三版

第 13 章 补丁 补丁

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

Git 允许使用推送模式和拉动模式将开发工作直接 并立即从一个仓库传输到另一个仓库。它通过我们在"引用远程仓库 "一文中讨论过的各种支持协议来实现。

简单回顾一下，Git 实现了 自己的传输协议，用于在版本库之间交换数据。为了节省时间和空间，Git 的传输协议会进行一次小规模握手，确定源仓库中哪些提交在目标仓库中缺失，最后传输二进制压缩形式的提交。接收版本库会将新提交纳入本地历史，扩充提交图，并根据需要更新分支和标签。

HTTP 也可用于在版本库之间交换开发 。虽然 HTTP 的效率远不及 Git 的原生协议，但它同样能在不同版本库之间传输提交。这两种协议都能确保传输的提交在源版本库和目标版本库中保持一致。

在现代 Git 托管平台中，将多个版本库工作副本中的变更系统地纳入一个集中的真实源的操作 ，与 HTTP 几乎相同。在推拉模式的底层基础上引入了新的工作流程和功能。事实上，你可能已经知道拉取请求或合并请求，这取决于你选择的 Git 托管平台。我们将在第 18 章详细介绍拉取请求。

不过，这些功能和协议并不是 交换提交和保持分布式源同步的唯一机制。事实上，有时使用这些协议并不可行。借鉴早期 Unix 开发时代久经考验的方法，Git 还支持 "补丁和应用 "操作，数据交换通常通过电子邮件进行。

Git 实现了三种特定的命令，以方便交换补丁：

• git format-patch 生成电子邮件形式的补丁。

• git send-email 通过简单邮件传输协议 (SMTP) 发送 Git 补丁。

• git am 应用在电子邮件中找到的补丁。

典型的用例相当简单。您和一位或多位开发人员从一个公共版本库的克隆开始协作开发。您做了一些工作，对您的版本库副本进行了一些提交，最终决定是时候将您的更改传达给您的合作伙伴了。您可以选择要共享的提交，也可以选择与谁共享工作。由于补丁是通过电子邮件发送的，因此每个收件人都可以选择不使用、使用部分或全部补丁。

在本章中，我们将首先解释何时需要使用补丁，然后举例说明如何生成、发送和（如果是接收者）应用补丁。由于打补丁基本上是将一个版本库中的变更合并到另一个版本库中，因此我们还讨论了打补丁与合并的不同概念。

为什么使用补丁？

尽管 Git 协议比 HTTP 高效得多， ，但至少有两个令人信服的理由让我们不得不承担补丁所需的额外工作：一个是技术上的，另一个是社会学上的：

• 在某些情况下，无论是 Git 本地协议 还是 HTTP，都无法在版本库之间以推或拉或两者兼有的方式交换数据。

  例如，公司防火墙可能禁止使用 Git 的协议或端口打开与外部服务器的连接。此外，SSH 可能也不是一种选择。此外，即使允许使用 HTTP（这很常见），你也可以下载软件源并获取更新，但可能无法将更改推送回去。在这种情况下，电子邮件是沟通补丁的最佳媒介。

• Git 等点对点开发模式的一大优势就是协作。补丁，尤其是那些发送到公共邮件列表的补丁，是一种公开发布修改建议供同行审查的手段。

  在将补丁永久应用到版本库之前，其他开发人员可以对发布的补丁进行讨论、批评、修改、测试，并批准或否决。由于补丁代表了精确的更改，因此可以直接将可接受的补丁应用到版本库中。

  即使您的开发环境允许您方便地进行直接推送或拉动交换，，您可能仍然希望采用 "打补丁、发邮件、审核和应用 "的模式，以获得同行评审的好处。

  您甚至可以考虑制定一项项目开发政策，规定每个开发人员的修改都必须先在邮件列表中作为补丁经过同行评审，然后才能直接通过 ...