Git(进程): Use Rebase or Double QA?

Question

我们的商店有一个相当快的部署周期(从编写代码到发布代码需要 1-2 周)。因此，经过一些实验后，我们采用了以下 Git 使用模式:

1. 开发人员基于 master 为他们的特定工单创建一个分支(即“bug-5555”分支)
2. 开发人员提交修复该分支的代码
3. 主管将我们的“pre-master”分支(master 的副本和当前发布的候选版本放在它的顶部) rebase 到 bug 分支
4. 主管将 bug 分支的提交 merge (快进式)到 pre-master 分支
5. QA 团队负责 pre-master 分支中的修复
6. 如果修复未通过 QA，则将其从 pre-master 分支中重新定位
7. (完成 QA 故障修复后，重复步骤 3-5)
8. 当我们准备好发布时，pre-master 分支成为新的 master 分支

这种风格对我们有很多好处:它使 QA 团队能够准确地测试将要上线的内容，它使我们可以轻松地放入和取出东西在 QA 之外，它将特定修复的代码保存在自己的分支中，等等。

然而，这里有几个人担心我们使用 rebase(既要在将当前的 pre-master 分支 merge 到 pre-master 之前将当前的 pre-master rebase 到 fix 分支，又要将 pre-master 分支 rebase 以采取出失败的修复)。他们担心 rebase 可能会导致历史丢失，因此我们应该尽可能少地 rebase 。

但是，在不进行 rebase 的情况下，我们想出的唯一替代方案是使 pre-master 分支成为死胡同分支，仅用于 QA。这将使该分支的 rebase 更安全，并且当我们准备好发布时，我们会将修复分支直接重新 merge 到 master 中。这种方法的问题在于 QA 实际上不会测试正在运行的内容，并且不正确的 merge 冲突解决方案(当将修复程序 merge 到 master 中时)很容易被他们忽略(除非他们重新对所有内容重新进行质量检查) .这是我们坚持当前方法的主要原因，尽管存在 rebase 问题。

所以，在很长的前奏结束后，我真正的问题是......好吧，它分为两部分:

1. 您认为哪个更糟糕:没有对正在上线的内容进行 QA 的风险，或者我们所做的(有限)数量的 rebase 丢失历史记录(或实际代码)的风险？
2. 有没有人看到我所概述的第三种选择，这将为我们提供相同的灵 active 和测试实际要上线的内容，而没有 rebase 的危险？

Answer 1

一般来说，如果没有一个良好的机制来跟踪正在运行的事物(可能在您的 SCM 系统本身之外，例如，在您的错误跟踪器中)，我同意将事物 rebase 通常是危险的。

有(至少)2 个以上关于如何使用 Git 分支管理发布过程的非常好的资源。

• gitworkflows(7)描述 git 开发人员如何管理他们自己的发布过程。
• Junio Hamano(git 维护者)在他自己关于如何处理集成传入功能的描述中对此进行了扩展:maintain-git.txt .
• 在“A successful Git branching model”中，Vincent Driessen 描述了一个略有不同的模型。

Git 本身使用一个“建议的更新”分支(称为 pu)来反射(reflect)您的 pre-master 分支。该分支由来自各种修复分支的 merge 组成。该分支用于需要测试和集成的真正不稳定的功能。它可以相对自由地重新设置和重置。 (同样，每个单独的主题/功能分支都在 Git 之外进行跟踪)。功能通常只 merge 到 pu 中一次，并且 pu 会定期针对更稳定的内容进行重置。

更稳定的更改被 merge 到 next 中以进行更广泛的测试。同样，这是通过 merge 处理的，而不是 rebase 。您的 pre-master 分支与 next 和 pu 的用途相似。一个功能可能会多次 merge 到 next 中，以 merge 其他反馈。尽管如此，主题分支仍会进行开发。

当主题分支被认为足够稳定时，它会被 merge 到master。

为了帮助跟踪正在发生的事情，Git 有一个“What's Cooking”的概念。 Git 维护者 Junio Hamano 拥有 a script called cook这有助于让每个人都明白事情的真相，以及各个主题分支所处的状态。

当然，Git 没有明确的 QA 流程；在您的情况下，有了真正的 QA 团队，您可以做一些事情的组合。

• 在步骤 (3) 中针对 master 的 rebase 没问题。它们是开发的合理部分。
• 不要 merge 快进风格，而是按照 Driessen 的建议并使用 --no-ff 明确跟踪分支出处。
• 为了处理 QA 检测到的故障，通过重置和重新 merge 重新创建 pre-master 分支，或通过还原 merge 提交，或 通过 merge 出现在旧修复分支之上的新修复。
• 当您准备好发布到 master 时，创建一个新的集成分支，它直接 merge 所有来自每个修复分支的成功修复一次。您可以验证此树确实是 QA 测试的代码(例如，git diff integration pre-master 为空)。然后将集成分支 merge 到 master 中(同样，使用 --no-ff 来跟踪是谁在何时完成的)。
• 对于下一个周期，您可以通过执行 git checkout pre-master 从头开始​​重新创建 pre-master； git reset --hard master，或者你可以从master做一个大概微不足道的 merge (解决所有有利于master的冲突，例如git checkout pre-master; git merge -s recursive -X theirs master).
• 如果需要，您可以在 pre-master 中使用标签来跟踪 QA 的特定版本。

这里的区别主要是使用 merge 来帮助您跟踪 merge 的内容以及 merge 的时间和 merge 者。 merge 的另一个好处是开发人员(和 QA)将看到更少的强制更新，更多的只是定期更新。

再次强调，真正要强调的是，必须有一些东西用于跟踪已 merge (或重新设置)到稳定分支并成功测试的内容。