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 分支，其中基本上包含稳定代码。当你认为内容分支中的工作已经完成，或者其他人已经贡献并验证了工作时，你将其合并到你的 master 分支，删除刚合并的内容分支，然后重复。

例如，如果我们有一个存储库，其中有两个名为 ruby_client 和 php_client 的分支，它们看起来像 包含多个内容分支的历史记录，并且我们先合并 ruby_client，然后合并 php_client，那么你的历史记录最终将看起来像 内容分支合并后的历史记录。

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

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

这样，当人们克隆你的项目的仓库时，他们可以检出 master 来构建最新的稳定版本，并方便地保持最新状态，或者他们可以检出 develop，它包含更前沿的内容。你也可以扩展这个概念，通过创建一个 integrate 分支，所有工作都合并到一起。然后，当该分支上的代码库稳定并通过测试后，你将它合并到 develop 分支；当它经过一段时间证明其稳定性后，你将你的 master 分支快速向前移动。

Git 项目有四个长期运行的分支：master、next 和 seen（以前为 'pu' - 提议的更新）用于新工作，以及 maint 用于维护回溯。当贡献者引入新的工作时，它们会被收集到维护者仓库中的主题分支中，方式类似于我们之前描述的（见 管理一系列并行的贡献者主题分支）。此时，会评估这些主题，以确定它们是否安全且已准备好使用，或者它们是否需要更多工作。如果它们是安全的，它们将被合并到 next 中，并且该分支会被推送到上面，这样每个人都可以尝试将主题整合到一起。

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

当主题分支最终被合并到 master 后，它将从仓库中删除。Git 项目还有一个 maint 分支，它从最后一个版本分支出来，以提供回溯的补丁，以防需要维护版本。因此，当你克隆 Git 仓库时，你有四个分支可以检出，以评估不同开发阶段的项目，具体取决于你想要达到的前沿程度或你想要做出贡献的方式；并且维护者有一个结构化的工作流来帮助他们审查新的贡献。Git 项目的工作流是专门的。要清楚地理解这一点，你可以查看 Git 维护者指南。

其他维护者更喜欢将贡献者提交的工作变基到他们的 master 分支上，而不是合并它，以保持一个基本上线性的历史记录。当你有一个主题分支中的工作，并且你已经确定想要将其整合进来时，你移动到该分支，并运行变基命令，以在当前的 master（或 develop 等）分支之上重建更改。如果这很顺利，你就可以快速向前移动你的 master 分支，最终你会得到一个线性的项目历史记录。

将引入的工作从一个分支移动到另一个分支的另一种方法是 cherry-pick 它。Git 中的 cherry-pick 就像对单个提交的变基。它获取提交中引入的补丁，并尝试将其重新应用到你当前所在的分支上。如果你在一个主题分支上有多个提交，并且你只想要整合其中一个，或者如果你在一个主题分支上只有一个提交，并且你更喜欢 cherry-pick 而不是运行变基，这将很有用。例如，假设你的项目看起来像这样

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

这会拉取 e43a6 中引入的相同更改，但你会得到一个新的提交 SHA-1 值，因为应用的日期不同。现在你的历史记录看起来像这样

现在你可以删除你的主题分支，并删除你不想拉取的提交。

如果你做了大量的合并和变基，或者你维护了一个长期存在的主题分支，Git 拥有一个叫做 "rerere" 的功能，可以帮助你。

Rerere 代表 "reuse recorded resolution" - 它是简化手动冲突解决的一种方式。当 rerere 启用时，Git 会保存一组来自成功合并的预先和事后的镜像，并且如果它注意到有一个与你之前已经解决的冲突完全相同的冲突，它会简单地使用上次的修复，而不会再让你烦恼。

此功能包含两个部分：一个配置设置和一个命令。配置设置是 rerere.enabled，它足够方便，可以放在你的全局配置中

现在，无论何时你执行一个解决冲突的合并，该解决方案都将被记录在缓存中，以备将来使用。

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