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

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

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

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

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

这提供了非常可控的修复流程。 如果您注意到您已将修复应用于 master 等，并且 maint 也需要该修复，则需要向下 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 hook 来执行与发布相关的项目，例如构建发布 tarballs 和预格式化的文档页面。

类似地，对于维护版本，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] 来向 upstream 维护者发送预格式化的 pull 请求，以简化此任务。）

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

然后，只需像之前解释的那样，从稳定的 remotes 分支你的主题分支。

如果你是维护者，并且想将其他人的主题分支合并到集成分支中，他们通常会通过邮件发送请求来执行此操作。这样的请求看起来像

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

有时，维护者在尝试从下游拉取更改时可能会遇到合并冲突。在这种情况下，他们可以要求下游进行合并并自己解决冲突（也许他们更了解如何解决它们）。这是下游应该从上游合并的罕见情况之一。

如果你是一个以电子邮件形式向上游发送更改的贡献者，你应该像往常一样使用主题分支（见上文）。然后使用 git-format-patch[1] 生成相应的电子邮件（强烈推荐，因为它使维护者的生活更轻松）。

有关更多用法说明，请参见 git-format-patch[1] 和 git-send-email[1] 手册页。

如果维护者告诉你你的补丁不再适用于当前的上游，你将不得不 rebase 你的主题（你不能使用合并，因为你不能 format-patch 合并）

然后你可以在 rebase 期间修复冲突。据推测，除了通过邮件之外，你没有发布你的主题，因此 rebasing 它不是问题。

如果你收到这样的补丁系列（作为维护者，或者作为发送到邮件列表的读者），将邮件保存到文件，创建一个新的主题分支，并使用 git am 导入提交

一个值得指出的功能是三向合并，它可以帮助你解决冲突：git am -3 将使用补丁中包含的索引信息来确定合并基础。有关其他选项，请参见 git-am[1]。