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 进程将失败并询问你想要做什么：

此命令会在任何有问题的文件中放置冲突标记，非常类似于冲突的合并或 rebase 操作。你解决这个问题的方式大致相同——编辑文件以解决冲突，暂存新文件，然后运行 git am --resolved 以继续下一个补丁：

如果你想让 Git 更智能地尝试解决冲突，可以向其传递 -3 选项，这会使 Git 尝试进行三方合并。此选项默认不启用，因为如果补丁声明其所基于的提交不在你的仓库中，它将不起作用。如果你确实拥有该提交——如果补丁是基于一个公共提交——那么 -3 选项在应用冲突补丁时通常会更智能：

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

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

如果你保存了多个补丁，这会很方便，因为如果你不记得补丁是什么，可以先查看它，或者如果你已经应用过该补丁，则不应用它。

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

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

例如，如果我们的仓库中有两个名为 ruby_client 和 php_client 的分支，其工作情况如下所示：包含多个主题分支的历史，如果我们先合并 ruby_client 再合并 php_client，你的历史记录将如下所示：主题分支合并后。

这可能是最简单的工作流，但如果你正在处理更大或更稳定的项目，并且希望对引入的内容非常谨慎，那么这可能会有问题。

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

这样，当人们克隆你的项目仓库时，他们既可以检出 master 来构建最新的稳定版本并轻松保持更新，也可以检出 develop，这是更前沿的内容。你还可以扩展这个概念，设置一个 integrate 分支，所有工作都在其中合并。然后，当该分支上的代码库稳定并通过测试时，你将其合并到 develop 分支；当 develop 分支已经稳定一段时间后，你再快进你的 master 分支。

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

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

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

其他维护者倾向于在其 master 分支之上 rebase 或 cherry-pick 贡献的工作，而不是合并它，以保持大部分线性的历史记录。当你的主题分支中有工作并确定要集成它时，你切换到该分支并运行 rebase 命令，以在当前 master（或 develop 等）分支之上重建更改。如果这顺利进行，你可以快进你的 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。