随着给定功能从实验性过渡到稳定性，它也会在软件的相应分支之间“毕业”。git.git 使用以下集成分支

还有一个第四个官方分支的使用方式略有不同

这四个分支中的每一个通常都是其上一个分支的直接后代。

从概念上讲，该功能进入不稳定的分支（通常是next 或seen），并在被认为足够稳定后“毕业”到master 以供下一个版本使用。

但是，上面讨论的“向下毕业”不能通过实际向下合并来完成，因为这会将不稳定分支上的所有更改合并到稳定分支中。因此以下

这提供了非常受控的修复流程。如果您注意到您已将修复应用于例如需要在maint 中使用的master，则需要将其向下 cherry-pick（使用 git-cherry-pick[1]）。这将发生几次，除非您非常频繁地这样做，否则无需担心。

任何重要的功能都需要多个补丁来实现，并且在其生命周期中可能会获得额外的错误修复或改进。

直接在集成分支上提交所有内容会导致许多问题：错误的提交无法撤消，因此必须逐个撤消，这会创建混乱的历史记录并在您忘记撤消一部分更改时进一步增加错误的可能性。并行工作会混淆更改，造成进一步的混乱。

使用“主题分支”可以解决这些问题。名称不言而喻，但有一点需要注意，它来自上面的“向上合并”规则

然后可以非常自然地完成许多事情

请注意，最后一点与其他两点冲突：已合并到其他地方的主题不应重新设置其基础。请参阅 git-rebase[1] 中的“从上游重新设置基础中恢复”部分。

我们应该指出，“习惯性”（定期且没有真正理由）地将集成分支合并到您的主题中，并且由此扩展，定期将任何上游内容合并到任何下游内容的做法是不被推荐的

否则，合并到的主题将突然包含多个（分离的）更改。许多由此产生的小型合并将极大地扰乱历史记录。任何稍后调查文件历史记录的人员都必须找出该合并是否影响了开发中的主题。上游甚至可能无意中被合并到“更稳定”的分支中。等等。

如果您遵循上一段，现在您将拥有许多小的主题分支，并且偶尔会想知道它们是如何交互的。也许合并它们的结果甚至不起作用？但另一方面，我们希望避免将它们合并到任何“稳定”的地方，因为此类合并不容易撤消。

当然，解决方案是进行可以撤消的合并：合并到一次性分支中。

如果您明确表示此分支将在测试后立即删除，您甚至可以发布此分支，例如让测试人员有机会使用它，或让其他开发人员有机会查看他们正在进行的工作是否兼容。git.git 拥有一个名为 seen 的此类官方一次性集成分支。

假设您正在使用上面讨论的合并方法，当您发布项目时，您需要执行一些额外的分支管理工作。

功能发布是从 master 分支创建的，因为 master 跟踪应包含在下一个功能发布中的提交。

master 分支应该包含 maint。如果此条件不成立，则 maint 包含一些未包含在 master 中的提交。因此，这些提交所代表的修复将不会包含在您的功能发布中。

要验证 master 是否确实是 maint 的超集，请使用 git log

此命令不应该列出任何提交。否则，检出 master 并将 maint 合并到其中。

现在您可以继续创建功能发布。在 master 的顶端应用一个标签，指示发布版本

您需要将新标签推送到公共 Git 服务器（请参阅下面的“分布式工作流”）。这使得所有跟踪您项目的其他人可以使用该标签。推送还可以触发 post-update 钩子来执行与发布相关的项目，例如构建发布压缩包和预格式化的文档页面。

类似地，对于维护发布，maint 正在跟踪要发布的提交。因此，在上面的步骤中，只需标记和推送 maint 而不是 master。

功能发布后，您需要管理您的维护分支。

首先，如果您希望继续发布对之前发布的功能发布的维护修复，则必须创建另一个分支来跟踪该先前发布的提交。

为此，当前维护分支将复制到另一个分支，该分支以先前的发布版本号命名（例如 maint-X.Y.(Z-1)，其中 X.Y.Z 是当前发布）。

maint 分支现在应该快进到新发布的代码，以便可以跟踪当前发布的维护修复

如果合并失败，因为这不是快进，那么功能发布中可能错过了 maint 上的一些修复。如果如上一节所述验证了分支的内容，则不会发生这种情况。

功能发布后，可以根据需要使用 next 上现有的主题，将集成分支 next 重绕并从 master 的顶端重新构建。

这样做的优点是 next 的历史将是干净的。例如，合并到 next 的一些主题最初可能看起来很有希望，但后来发现是不希望的或过早的。在这种情况下，主题将从 next 中回退，但历史记录中仍然存在它曾经被合并和回退的事实。通过重新创建 next，您可以为这些主题的另一个化身提供一个干净的起点来重试，并且功能发布是历史上的一个很好的时间点来做到这一点。

如果这样做，则应发布公开公告，表明 next 已重绕并重建。

相同的重绕和重建过程可以应用于 seen。由于 seen 是一个一次性分支，如上所述，因此无需发布公开公告。

合并工作流通过在上游和下游之间复制分支来工作。上游可以将贡献合并到官方历史记录中；下游基于官方历史记录开展工作。

有三个主要工具可用于此目的

注意最后一点。除非您确实想要合并远程分支，否则不要使用git pull。

发布更改很容易

您仍然必须通过其他方式告诉人们，例如邮件。（Git 提供了 git-request-pull[1] 用于向上游维护者发送预格式化的拉取请求，以简化此任务。）

如果您只想获取集成分支的最新副本，保持最新也很容易

然后，只需根据前面所述从稳定的远程分支派生您的主题分支。

如果您是维护者，并且希望将其他人的主题分支合并到集成分支，他们通常会通过邮件发送请求这样做。

在这种情况下，git pull 可以一次完成获取和合并，如下所示。

偶尔，维护者在尝试从下游拉取更改时可能会遇到合并冲突。在这种情况下，他们可以要求下游执行合并并自行解决冲突（也许他们会更好地知道如何解决冲突）。这是下游应该从上游合并的少数几个情况之一。

如果您是贡献者，并且以电子邮件的形式向上游发送更改，则应照常使用主题分支（请参见上文）。然后使用 git-format-patch[1] 生成相应的电子邮件（强烈建议不要手动格式化它们，因为这会使维护者更容易）。

请参阅 git-format-patch[1] 和 git-send-email[1] 手册页以获取更多用法说明。

如果维护者告诉您您的补丁不再适用于当前的上游，则您必须重新设置您的主题（您不能使用合并，因为您无法格式化补丁合并）

然后您可以在重新设置期间修复冲突。据推测，您除了通过邮件发布主题之外，没有发布过其他内容，因此重新设置主题没有问题。

如果您收到此类补丁系列（作为维护者，或者可能是邮件列表的读者），请将邮件保存到文件中，创建一个新的主题分支并使用git am导入提交

值得指出的一项功能是三方合并，如果遇到冲突，它可以提供帮助：git am -3 将使用补丁中包含的索引信息来确定合并基础。有关其他选项，请参阅 git-am[1]。