问题将Git Feature分支合并到"Beta"分支(在它已经合并到"Develop"分支之后)

Question

我们有一个标准的Web项目,并为该项目维护3个核心分支:Master,Beta和Develop.以下是我们使用的流程/工作流程的摘要:

(1)请求新功能/更新,以便我们创建新的功能分支.

(2)为新功能分支进行提交,并将功能分支合并到"开发"分支中; 然后将"开发"分支发布到要测试的测试环境.

(3)测试/批准新功能后,在同一功能分支中进行新的拉取请求; 这个新的pull请求被合并到'Beta'分支中.

'Beta'分支拥有我们所有的"准备就绪"功能:事实上,我们将'Beta'分支直接发布到生产环境,当它准备就绪时,我们立即将'Beta'分支合并到'Master'分支......通过这样做,'Master'分支始终是生产环境中代码的副本.

问题:在上面的步骤3中,当我们尝试将新的Feature分支合并到'Beta'分支时,pull请求包括已合并到'Develop'分支的所有新提交.

示例:5个要素分支分别合并到"Develop"分支(分支标记为1,2,3,4和5).所有5个都经过了测试,但是前面有4个错误.所以分支"5"被批准,我们尝试为该功能分支创建一个拉取请求并将其合并为"Beta"....但是当我们这样做时, pull请求包括所有5个功能分支....而不仅仅是分支"5"的提交.

我们必须做错事!我们可以做些什么来修复我们的流程/工作流程？

Answer 1

(3)测试/批准新功能后,在同一功能分支中进行新的拉取请求; 这个新的pull请求被合并到'Beta'分支中.

'Beta'分支拥有我们所有的"准备就绪"功能:事实上,我们将'Beta'分支直接发布到生产环境,当它准备就绪时,我们立即将'Beta'分支合并到'Master'分支......通过这样做,'Master'分支始终是生产环境中代码的副本.

问题:在上面的步骤3中,当我们尝试将新的Feature分支合并到'Beta'分支时,pull请求包括已合并到'Develop'分支的所有新提交.

不,这没有意义.如果发生这种情况,您就省略了重要信息,例如:

• 每个新功能分支都从另一个分支分支出来.哪一个,发展？然后很明显,无论开发提交是否在新创建的功能的历史中,也将合并到beta分支中.Git历史是一个有向无环图,每个提交指向一个(正常提交)或多个(合并提交)父提交.
• 为了使功能完全合并到开发中,可能会将功能分支定期重新定位到开发中,或者可能通过合并最新的开发来更新功能分支,这两者都很有意义,我提倡它.但在这种情况下,他们的历史也包含了合并/变基时的所有发展历史.

在每种情况下,您的工作流程都会从根本上被打破,并且无法满足您对beta分支的看法.因此,如果你想避免挑选(糟糕!糟糕!糟糕!)你怎么能实现你想做的事情？有一些基本选择:

1. 功能切换:丑陋.我会尽可能远离它.在任何分支中停用功能的最佳方法是首先在该分支上没有相应的提交.
2. 干净利落地工作:好.避免合并未经测试/未接受的功能以进行开发.只有在完成后才会合并(如"完成定义")并由客户接受.确保您设置了一个环境,使您的客户可以直接在功能分支上进行测试,而不是将其全部压缩到测试版分支上.这样开发的任何内容都固有地为生产做好准备,您不再需要beta分支.未完成的工作永远不会被合并到更高级别的分支.这就是GitFlow的全部内容,它的工作原理.即使你没有完全使用GitFlow,但只是掌握,开发和功能分支,我的陈述的有效性仍然存在.我在很多项目中都是这样工作的,而且效果很好.此外,如果您认为需要另一个分支来集成功能以用于将来的版本,请为它们创建一个新的"next_release"或"future"分支,并将它们合并到该分支,而不是开发.然后定期从开发中刷新未来,因为您还希望在将来的版本中使用当前版本中的功能,但反之亦然.我不相信这个额外的步骤是必要的.

Answer 2

这就是 git 的工作方式。您需要为每个功能创建单独的分支。