git - 将 Git Feature 分支 merge 到 "Beta"分支的问题(在它已经 merge 到 "Develop"分支之后)

Question

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

(1) 请求新功能/更新，因此我们创建一个新的功能分支。

(2) 提交新的Feature分支，并将Feature分支 merge 到'Develop'分支；然后将“开发”分支发布到测试环境进行测试。

(3) 一旦新功能被测试/批准，在同一个功能分支中进行新的 pull 请求；这个新的 pull 请求旨在 merge 到“Beta”分支中。

“Beta”分支具有我们所有的“准备上线”功能:实际上，我们将“Beta”分支直接发布到生产环境，准备就绪后我们立即 merge “Beta”分支到“主”分支....通过这样做，“主”分支始终是生产环境中代码的副本。

问题:在上面的第 3 步中，当我们尝试将新功能分支 merge 到“Beta”分支时， pull 请求包括已 merge 到“开发”分支的所有新提交。

示例:5 个功能分支分别 merge 到“开发”分支(分支标记为 1、2、3、4 和 5)。所有 5 个都经过测试，但前 4 个存在错误。因此分支“5”获得批准，我们尝试为该功能分支创建 pull 请求并将其 merge 到“Beta”....但是当我们这样做时， pull 请求包括所有 5 个功能分支....而不仅仅是分支“5”的提交。

我们一定是做错了什么!我们可以做些什么来修复我们的流程/工作流程？

Answer 1

(3) Once the new feature is tested/approved, a new pull request is made in the same Feature branch; this new pull request is meant to be merged into the 'Beta' branch.

The 'Beta' branch has all of our "ready-to-go-live" features: in fact, we publish the 'Beta' branch directly to the production environment and when that is ready we immediately merge the 'Beta' branch to the 'Master' branch....by doing this, the 'Master' branch is always a copy of the code that is on the production environment.

The problem: in step 3 above, when we try to merge the new Feature branch into the 'Beta' branch, the pull request includes ALL new commits that have been merged into the 'Develop' branch.

不，那没有意义。如果发生这种情况，您遗漏了重要信息，例如:

• 每个新功能分支都是从另一个分支分支出来的。哪一个，开发？那么很明显，无论新创建功能的历史记录中的开发提交，也将 merge 到 beta 分支中。 Git 历史是一个有向无环图，每个提交都指向一个(正常提交)或多个( merge 提交)父提交。
• 为了使功能干净利落地 merge 到开发中，也许功能分支定期重新基于开发，或者功能分支通过 merge 到最新的开发中得到刷新，这两种方法都很有意义，我提倡这样做。但在这种情况下，他们的历史也包含 merge/ rebase 时的所有开发历史。

在每一种情况下，您的工作流程都从根本上被破坏并且无法按照您关于测试版分支的想法工作。因此，如果您想避免 cherry-pick (糟糕!糟糕!糟糕!)，您如何才能实现您想要做的事情？有一些基本选项:

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