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 文件而构建的，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，你确定只有在发布非常稳定的版本时才更新 master，所有新代码都集成到 develop 分支中。你定期将这两个分支推送到公共仓库。每次你有一个新的主题分支要合并时（主题分支合并前），你将其合并到 develop（主题分支合并后）；然后，当你标记发布时，你将 master 快进到现在稳定的 develop 分支所在的位置（项目发布后）。

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

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

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

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

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

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

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

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

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

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

Rerere 代表“reuse recorded resolution”（重用已记录的解决方案）——它是一种简化手动冲突解决的方法。当启用 rerere 时，Git 会保留一组成功合并的预图像和后图像，如果它发现一个冲突看起来与你已经解决的冲突完全相同，它就会直接使用上次的解决方案，而无需打扰你。

这个功能由两部分组成：一个配置设置和一个命令。配置设置是 rerere.enabled，它非常方便，可以放到你的全局配置中

现在，每当你进行一次解决冲突的合并时，解决方案都将记录在缓存中，以备将来需要。

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