将项目分支合并到演示分支的正确程序

Question

下图构成了我希望我们的开发环境如何进行的所需流程。有4个标准分支，ProdMaster，TestMaster，DevMaster和master。假设以上四个是在同一基线开始的，那么三个不同的开发人员可以各自创建一个新项目或从master分支到功能分支。一旦开发完成，每个人都将其更改合并到DevMaster中。 Dev主要用于演示和测试，因此可以说Project \ Feature分支2被批准可以进行测试，而1和3则没有。然后，我希望能够接管Project Branch 2，并将其合并到测试中，而无需移交Project Branch 1和3中发生的任何更改。

最初我们在GitHub中使用Merge Commits，但是我们注意到的是，如果Project Branch 1被合并，那么2和3被合并，第二个分支将从第一个分支获取提交，而第三个分支将从第一个分支获取提交。 2和3。

因此，我们尝试进行压缩和合并，这似乎奏效了，因为新的project \ feature分支不会感染来自基础分支的单独提交。这似乎大部分都是可行的，除了一个小的更改有时会显示在基础分支上已经进行的所有更改。有时这是由于冲突造成的，如果我将冲突纠正在一个文件中，则文件更改的数量将从130+变回1。我应该使用它作为基准吗？两者混合？还是我流量不正确？我和团队中的其他成员都进行了很多研究，即使发现了壁球和变基，也很难看到它们之间的实际区别。

Answer 1

这是可能的开发流程，是的，您正在寻找基础。

您可以使用批准的分支PB2，并将其重新建立到TestMaster上（假设此处TestMaster和master密切相关）。

您可以选择将所有更改压缩到一个提交中。

注1：分支PB1，PB2，PB3合并到DevMaster中后，它们将被“焊接”，并且不应被“取消合并”。您可以使用DevMaster进行批量测试，但是如果这是您的批准单位，则应将原始分支PB2用于TestMaster，或者一起拒绝所有3个更改。也许这就是为什么您会感到困惑？

注2：在您的描述中，我看不到“ master”和“ TestMaster”之间的区别，因为从本质上来说，两个分支都应包含准备好用于测试的已批准更改。

替代方法

您在此过程中分为四个阶段：

1. 在功能分支中开发
2. 在DevMaster上测试批准
3. 在TestMaster上进行测试
4. 等待在ProdMaster上发布

因此，除了拥有固定的分支（例如DevMaster，TestMaster，ProdMaster）之外，您还可以通过某种方式索引3个分支序列。例如，如果您使用产品的版本55，则可以拥有DevMaster55-1，DevMaster55-2，DevMaster55-3（如果有多个回合，则需要进行每一轮批准），TestMaster55（用于测试版本55）和ProdMaster55 （应正式投入生产的v55的实际版本）。

这样做的好处是您不必保持这些序列同步（例如，TestMaster56将与TestMaster55分开），并且每个分支上的更改历史都非常清晰。实际上，ProdMaster55可能只是TestMaster55分支上的标签，而TestMaster55是某个时候从master起飞的“稳定”分支，并且仅接受v55所需的修复程序。