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 格式，那么你就可以将 mbox 文件指向 git am，它将开始应用它看到的所有补丁。如果你使用的邮件客户端可以将多个电子邮件保存为 mbox 格式，你可以将整个补丁系列保存到一个文件中，然后使用 git am 一次应用一个。

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

你可以看到它干净地应用了，并且自动为你创建了新的提交。作者信息是从邮件的 From 和 Date 标头中获取的，提交信息是从邮件的主题和正文（在补丁之前）中获取的。例如，如果这个补丁是从上面的 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 分支；当它稳定一段时间后，你将 master 分支快进。

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

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

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

其他维护者更喜欢将贡献的工作 rebase 或 cherry-pick 到他们的 master 分支之上，而不是合并进去，以保持一个大致线性的历史。当你有一个主题分支中的工作并已决定将其集成，你切换到该分支并运行 rebase 命令，以在你的当前 master（或 develop 等）分支之上重建更改。如果工作进展顺利，你可以快进你的 master 分支，你最终会得到一个线性的项目历史。

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

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

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

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

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

Rerere 的意思是“重用已记录的解决”——这是一种简化手动冲突解决的方法。当 rerere 启用时，Git 会保存成功合并的前后图像集，如果它注意到一个冲突与你已经修复过的冲突完全相同，它就会直接使用上次的修复，而不会打扰你。

此功能包含两个部分：一个配置设置和一个命令。配置设置是 rerere.enabled，将其添加到全局配置中非常方便：

现在，无论何时你进行一个解决了冲突的合并，解决方法都会被记录在缓存中，以备将来需要。

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