这通常是gitworkflow 地址
您只合并feature 分支，而不是将A 合并到B、B 到C、C 到D 等等。
每个开发人员（或一组开发人员）都在 feature 分支上工作，并将其合并到 dev 以进行集成测试。
但是当涉及到合并到额外的开发生命周期步骤（在您的情况下进行测试，然后是 staging、qa、您想要的任何名称）时，您不要将 dev 合并到 test
您将选定的 feature 分支（最初合并到 dev）合并到您想要的分支（测试、暂存等）
这样，您只需选择您认为已准备好并一起工作的功能子集，而不是尝试将“未准备好”的功能从 dev 还原，然后将 dev 合并到 test。
我detail that model further here和illustrate it here
有一点很重要：dev 分支（用于将feature 分支集成在一起）是transient：它是为每个新版本创建/销毁的（而不是一个固定的永恒dev分支不时合并到master）。
您可以重新创建尽可能多的集成分支，以便一起测试功能（开发、测试、暂存等）。
然后，当准备就绪时，您只需将正确的 feature 分支合并到 master（或任何其他 release 分支），删除您的 dev 分支，然后为下一个版本重新创建它。
重复一遍：
feature 分支被多次合并：
- 一次到
dev 进行初始集成测试，
- 然后相同的
feature 分支直接再次合并到test 中（可以进行第二次构建，您不必在feature 中重新构建），
- 然后直接在
staging 中再次合并（每次都是因为feature 分支被认为已准备好进入下一个生命周期开发阶段）
您不从（例如）test 到staging 采摘樱桃。
您将已通过 test 的 feature 分支合并到集成生命周期的下一步（将 feature 合并到 staging 分支）
目前，Robert 仍在构建一项新功能，该新功能将影响某些文件和代码的重大更改。
因此，Andy 无法对代码进行任何修改来修复该错误，因为几乎所有代码都已更改。
是的，Andy 可以在 hotfix 分支中专门维护发布到生产环境中的最新代码。
Robert 和 Andy 都可以参与该分支，如果那里需要所述修复，他们将负责将他们的修复提交应用到 dev（由于代码已更改，也许该错误修复在 dev 中不再相关）
Andy 会从热分支合并到测试吗？因为我们的最后一步是test => staging => staging trx => master
这个答案的全部意义在于说明您不必从A 合并到B 到C。
对于hotfix 分支，您很少将其合并回其他任何地方，因为dev 或test 分支的代码自上一个版本以来已经有了很大的发展。您只需cherry-pick将您需要的修复提交回dev 或test。
feature 已经进入production 环境后，我会销毁那个feature 分支对吧？
嗯...是的，“销毁”feature 分支将删除指向该分支的指针。
但是作为所述分支的一部分的实际提交仍然可以从master 上完成的合并提交中看到。没关系，并且对于稍后调试该功能很有用：您可以稍后检查来自所述合并提交的第二个父级的提交，而不是大的最终合并提交：它们是来自旧功能分支的提交。
虽然新的feature A 分支已经在test 分支中，并且测试人员仍在对新的feature A 进行压力测试，但生产中存在错误，Andy 将修复hotfix 中的feature B 错误分支。
问题是，在Andy修复了hotfix分支的bug之后，那么Andy应该把当前的hotfix分支合并到哪里呢？
因为如果有bug，并且开发者已经修复了bug，它不会直接投入生产，测试人员会先做测试，检查bug是否已经真正修复。
您将需要一个 second test 分支专门用于测试修补程序（不过我会直接在 hotfix 上进行这些测试），然后合并回 master，以更新生产。
重点是：当您确定并行开发工作时（如“测试功能分支”和“测试修补程序”），需要单独的分支。
但同样，对于错误修复，这是典型的“紧急路径”，对于这种情况，您有一个较短的分支工作流程和一个专用的 test-hotfix 分支（根据需要命名）。
另一种方法是简单地重置 test 分支，然后只合并回您急需的分支（在本例中为 feature B）：测试，合并 B 到暂存等等...一直到master。
最后，一旦 B 准备就绪，您可以使用相同的测试分支重新添加（合并）feature A，并在 B 已经验证的环境中继续对 A 进行测试。
重置测试的缺点是它会阻止所有其他开发集成。
这就是为什么最好有一个专门的分支。