Git (流程)：使用重基还是双QA？

Question

我们的商店有一个相当快的部署周期(从编写代码到发布代码之间的1-2周)。因此，在进行了一些实验之后，我们采用了以下模式来使用Git：

1. 开发人员为他们的特定票证创建一个基于主版的分支(即。"bug-5555“分部)
2. 开发人员将修复程序的代码提交到该分支。
3. 一个主管将我们的“预母版”分支(当前发布候选版本的母版副本)重新定位到bug分支中。
4. 主管将错误分支的提交合并到预主分支(快速转发样式)。
5. QA团队qa在预科的修复
6. 如果一个修复程序在QA中失败，那么它将从预主分支中重新定位。
7. (完成QA故障修复后，重复步骤3-5 )
8. 当我们准备发布时，预主分支将成为新的主分支。

这种风格对我们来说有很多优点:它使QA团队能够准确地测试将要运行的内容，它使我们很容易将内容放入QA中，并将其从QA中提取出来，并在自己的分支中保留用于特定修复的代码，等等。

但是，这里有几个人担心我们使用重基(在将该修复分支合并到预主程序之前，将当前的预主程序重新定位到修复分支，以及将预主分支重基以删除失败的修复)。他们担心的是，重新基地可能会导致历史的丢失，因此，我们应该尽可能频繁地重新建立基地。

然而，在不重新调整基础的情况下，我们提出的唯一选择是使预主分支成为一个只用于QA的死胡同分支。这将使重新建立分支更加安全，并且当我们准备好发布时，我们会将修复分支直接合并到主服务器中。不过，这种方法的问题在于，QA实际上不会测试正在运行的内容，一个不正确的合并冲突解决方案(当将修复程序合并到掌握中时)可能很容易从它们身边溜走(除非它们再次将所有的内容重新qa)。这是我们坚持现有方法的主要原因，尽管我们担心的是这种情况。

所以，在这个漫长的前奏中，我的问题是.分为两部分：

1. 你认为哪一种更糟糕:不确定到底发生了什么的风险，还是因为(有限的)重新定位而丢失历史(或实际代码)的风险？
2. 有没有人看到我所描述的第三种选择，它能给我们提供同样的灵活性和测试，让我们在没有重新定位的危险的情况下，去实际生活？

Answer 1

总的来说，我同意，如果没有一个很好的机制来跟踪正在飞行中的东西(这可能在SCM系统本身之外，例如在您的bug跟踪器中)，将其重新定位为一种规则可能是危险的。

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

• gitworkflows(7)描述了git开发人员如何管理自己的发布过程。
• Junio ( git维护者)在他自己关于如何集成进来的特性的描述中对此进行了扩展：maintain-git.txt。
• 在"一个成功的Git分支模型“中，文森特·德里森描述了一个略有不同的模型。

Git本身使用了一个“建议更新”分支(称为pu)，它反映了您的pre-master分支。这个分支由来自各种固定分支的合并组成。这个分支用于非常不稳定的特性，需要进行测试和集成。它可以相对自由地重新建立和重置。(同样，每个单独的主题/特性分支都在Git之外被跟踪)。通常只有一次将特性合并到pu中，而pu则会根据更稳定的特性定期进行重置。

更稳定的更改被合并到next中以进行更广泛的测试。同样，这是通过合并而不是重基来处理的。您的pre-master分支与next和pu具有类似的功能。一个特性可能会被多次合并到next中，以包含更多的反馈。然而，开发仍然发生在主题分支上。

当主题分支被认为足够稳定时，它将被合并到master中。

为了帮助跟踪正在发生的事情，Git有一个“烹饪的东西”的概念。Junio是Git的维护者，他拥有cook，它可以帮助每个人保持清晰的状态，以及不同的主题分支在哪个州。

当然，Git没有明确的QA流程；在您的示例中，有了一个真正的QA团队，您可以进行一些组合。

• 在你的第(3)步中，对大师的重新定位是可以的。它们是发展的合理组成部分。
• 与其合并快速转发风格，不如照Driessen的建议做，并使用--no-ff显式跟踪分支来源。
• 为了处理QA检测到的故障，通过重置和重新合并，或者通过恢复合并提交，或者通过合并到出现在旧修复分支之上的新修复，重新创建pre-master分支。
• 当您准备发布到master时，创建一个新的集成分支，它只从每个修复分支中直接合并所有成功的修复。您可以验证这棵树实际上是QA测试的代码(例如，git diff integration pre-master是空的)。然后将集成分支合并到主(同样，使用--no-ff跟踪谁和何时)。
• 在下一个周期中，您可以通过执行一个pre-master从头开始重新创建git checkout pre-master; git reset --hard master，或者您可以从主服务器执行一个可能很小的合并(解决所有有利于主的冲突，例如git checkout pre-master; git merge -s recursive -X theirs master)。
• 如果愿意，您可以使用标记跟踪pre-master上QA的特定版本。

这里的不同之处主要是利用合并来帮助您跟踪已经合并的内容以及合并的时间和对象。合并的另一个好处是，开发人员(和QA)将看到更少的强制更新，而更多的只是常规更新。

同样，真正要强调的是，必须有一些东西用来跟踪什么已经合并(或重新基于)到一个稳定的分支中，并成功地进行了测试。

Answer 2

总之，第二种策略是将主题分支合并为master，并将预主分支作为QA的中转区域。为了确保您确实发布了您的QAed，这个差异应该是空的(在您合并到成功地掌握QAed主题分支之后，并重新建立在预母版失败的QA主题分支之外)：

git diff pre-master master