5.3 分布式 Git - 维护项目

如果你收到的补丁来自使用 git diff 或 Unix diff 命令的某个变体生成它的人（不建议这样做；参见下一节），你可以使用 git apply 命令应用它。 假设你将补丁保存在 /tmp/patch-ruby-client.patch 中，你可以像这样应用补丁

这会修改你工作目录中的文件。 它几乎等同于运行 patch -p1 命令来应用补丁，尽管它更谨慎，并且接受的模糊匹配比 patch 少。 如果文件添加、删除和重命名在 git diff 格式中描述，它也会处理它们，而 patch 则不会。 最后，git apply 是一种“全部应用或全部中止”模型，其中要么全部应用，要么什么都不应用，而 patch 可以部分应用补丁文件，使你的工作目录处于奇怪的状态。 总的来说，git apply 比 patch 更保守。 它不会为你创建一个提交 —— 运行它后，你必须手动暂存和提交引入的更改。

你也可以使用 git apply 来查看补丁是否能够干净地应用，然后再尝试实际应用它 — 你可以使用 git apply --check 命令来检查补丁。

如果没有输出，那么该补丁应该可以干净地应用。如果检查失败，该命令也会以非零状态退出，所以你可以在脚本中使用它。

如果贡献者是 Git 用户，并且很乐意使用 format-patch 命令来生成补丁，那么你的工作就会更容易，因为该补丁包含作者信息和提交信息。如果可以，鼓励你的贡献者使用 format-patch 而不是 diff 来为你生成补丁。你只需要对遗留补丁和类似的事情使用 git apply。

要应用由 format-patch 生成的补丁，你需要使用 git am（该命令名为 am，因为它被用来“从邮箱应用一系列补丁”）。从技术上讲，git am 的构建目的是读取 mbox 文件，这是一种简单的纯文本格式，用于在一个文本文件中存储一个或多个电子邮件消息。它看起来像这样：

这是你在上一节中看到的 git format-patch 命令的输出的开始部分；它也代表了一种有效的 mbox 电子邮件格式。如果有人使用 git send-email 正确地通过电子邮件发送给你补丁，并且你将其下载到 mbox 格式，那么你可以将 git am 指向该 mbox 文件，它将开始应用它看到的所有补丁。如果你运行的邮件客户端可以将多个电子邮件保存为 mbox 格式，你可以将整个补丁系列保存到一个文件中，然后使用 git am 一次应用它们一个。

但是，如果有人将通过 git format-patch 生成的补丁文件上传到工单系统或类似的地方，你可以将该文件保存到本地，然后将磁盘上保存的该文件传递给 git am 以应用它：

你可以看到它被干净地应用了，并且自动为你创建了新的提交。作者信息取自电子邮件的 From 和 Date 标头，而提交的消息取自电子邮件的 Subject 和正文（在补丁之前）。例如，如果此补丁是从上面的 mbox 示例中应用的，则生成的提交将如下所示：

Commit 信息指示了应用补丁的人和应用时间。Author 信息是最初创建补丁的个人以及最初的创建时间。

但是，补丁可能无法干净地应用。也许你的主分支与构建补丁的分支偏离太远，或者补丁依赖于你尚未应用的另一个补丁。在这种情况下，git am 进程将失败并询问你想要做什么：

此命令会在它遇到问题的任何文件中放置冲突标记，就像冲突的合并或变基操作一样。你可以用几乎相同的方式解决此问题 — 编辑文件以解决冲突，暂存新文件，然后运行 git am --resolved 以继续处理下一个补丁。

如果你希望 Git 更智能地尝试解决冲突，你可以将 -3 选项传递给它，这会使 Git 尝试三方合并。默认情况下不启用此选项，因为如果补丁声明它基于的提交不在你的存储库中，则它不起作用。如果你确实有该提交 — 如果补丁基于公共提交 — 那么 -3 选项通常更智能地应用冲突补丁。

在这种情况下，如果没有 -3 选项，补丁将被视为冲突。由于使用了 -3 选项，补丁被干净地应用了。

如果你要从 mbox 应用大量补丁，你也可以在交互模式下运行 am 命令，该命令会在它找到的每个补丁处停止，并询问你是否要应用它：

如果你保存了大量补丁，这很好，因为你可以先查看补丁，如果你不记得它是什么，或者如果不应用补丁，如果你已经这样做了。

当主题的所有补丁都已应用并提交到你的分支后，你可以选择是否以及如何将它们集成到更长时间运行的分支中。

一个基本的工作流程是简单地将所有这些工作直接合并到你的 master 分支中。在这种情况下，你有一个包含基本稳定代码的 master 分支。当你在一个主题分支中完成了你认为已完成的工作，或者其他人贡献了你已验证的工作时，你将其合并到你的主分支中，删除刚刚合并的主题分支，然后重复此过程。

例如，如果我们有一个存储库，其中有两个名为 ruby_client 和 php_client 的分支中的工作，它们看起来像 具有多个主题分支的历史记录，并且我们合并了 ruby_client，然后合并了 php_client，那么你的历史记录最终会看起来像 主题分支合并之后。

这可能是最简单的工作流程，但如果你处理的是更大或更稳定的项目，并且你希望非常小心地对待你引入的内容，那么它可能会出现问题。

如果你有一个更重要的项目，你可能想要使用一个两阶段合并周期。在这种情况下，你有两个长时间运行的分支，master 和 develop，在其中你确定只有在切出一个非常稳定的版本时才更新 master，并且所有新代码都集成到 develop 分支中。你定期将这两个分支推送到公共存储库。每次你要合并一个新主题分支（主题分支合并之前）时，你都将其合并到 develop 中（主题分支合并之后）；然后，当你标记一个版本时，你将 master 快进到现在稳定的 develop 分支所在的位置（项目发布之后）。

这样，当人们克隆你的项目存储库时，他们可以检出 master 来构建最新的稳定版本并轻松地保持最新状态，或者他们可以检出 develop，这是更前沿的内容。你还可以通过拥有一个 integrate 分支来扩展这个概念，所有工作都合并到其中。然后，当该分支上的代码库稳定并通过测试时，你将其合并到 develop 分支中；当它被证明稳定了一段时间后，你将快进你的 master 分支。

Git 项目有四个长期运行的分支：master、next 和 seen (以前是 'pu' — 提议的更新) 用于新工作，以及 maint 用于维护反向移植。当贡献者引入新工作时，它们会以类似于我们描述的方式收集到维护者仓库中的主题分支中 (参见 管理一系列复杂的并行贡献主题分支)。此时，会对主题进行评估，以确定它们是否安全并已准备好使用，或者是否需要更多的工作。如果它们是安全的，它们将被合并到 next 中，并且该分支会被推送，以便每个人都可以尝试集成在一起的主题。

如果这些主题仍然需要工作，它们将被合并到 seen 中。当确定它们完全稳定后，这些主题将被重新合并到 master 中。然后从 master 重建 next 和 seen 分支。这意味着 master 几乎总是向前移动，next 偶尔会被 rebase，而 seen 则会被更频繁地 rebase。

当一个主题分支最终被合并到 master 中时，它会从仓库中删除。Git 项目还有一个 maint 分支，它是从上一个版本分叉出来的，以便在需要维护版本时提供反向移植的补丁。因此，当您克隆 Git 仓库时，您有四个分支可以检出，以评估不同开发阶段的项目，具体取决于您想要有多前沿或您想要如何贡献；维护者有一个结构化的工作流程来帮助他们审查新的贡献。Git 项目的工作流程是专门的。为了清楚地理解这一点，您可以查看 Git 维护者指南。

其他维护者更喜欢在他们的 master 分支上 rebase 或 cherry-pick 贡献的工作，而不是将其合并到其中，以保持大部分线性历史记录。当您在主题分支中有工作并且已确定要集成它时，您可以移动到该分支并运行 rebase 命令以在您当前的 master (或 develop 等) 分支之上重建更改。如果一切顺利，您可以 fast-forward 您的 master 分支，最终您将得到一个线性项目历史记录。

将引入的工作从一个分支移动到另一个分支的另一种方法是 cherry-pick 它。Git 中的 cherry-pick 就像单个提交的 rebase。它获取在提交中引入的补丁，并尝试将其重新应用于您当前所在的分支。如果您在主题分支上有许多提交并且只想集成其中一个提交，或者如果您在主题分支上只有一个提交并且您更喜欢 cherry-pick 它而不是运行 rebase，这将非常有用。例如，假设您有一个如下所示的项目

如果您想将提交 e43a6 拉到您的 master 分支中，您可以运行

这将拉取在 e43a6 中引入的相同更改，但您会获得一个新的提交 SHA-1 值，因为应用的日期不同。现在您的历史记录如下所示

现在您可以删除您的主题分支并删除您不想拉入的提交。

如果您正在进行大量的合并和 rebase，或者您正在维护一个长期存在的主题分支，Git 有一个名为“rerere”的功能可以帮助您。

Rerere 代表“reuse recorded resolution” — 它是简化手动冲突解决的一种方法。启用 rerere 后，Git 将保留一组来自成功合并的前后图像，如果它注意到存在与您已经修复的冲突完全相同的冲突，它将只使用上次的修复，而不会打扰您。

此功能分为两部分：一个配置设置和一个命令。配置设置是 rerere.enabled，将其放入您的全局配置中非常方便

现在，每当您进行解决冲突的合并时，解决方案将被记录在缓存中，以备将来需要时使用。

如果需要，您可以使用 git rerere 命令与 rerere 缓存进行交互。当单独调用时，Git 会检查其解决方案数据库并尝试查找与任何当前合并冲突的匹配项并解决它们（尽管如果 rerere.enabled 设置为 true，则会自动完成此操作）。还有一些子命令可以查看将要记录的内容、从缓存中删除特定解决方案以及清除整个缓存。我们将在 Rerere 中更详细地介绍 rerere。