将 Git Feature 分支合并到“Beta”分支中的问题（在它已经合并到“Develop”分支之后）

Question

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

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

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

(3) 一旦新特性被测试/批准，就会在同一个特性分支中提出一个新的拉取请求；这个新的拉取请求旨在合并到“Beta”分支中。

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

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

示例：5 个功能分支单独合并到“开发”分支（分支标记为 1、2、3、4 和 5）。所有 5 个都经过测试，但前 4 个存在错误。因此分支“5”被批准，我们尝试为该功能分支创建拉取请求并将其合并到“Beta”....但是当我们这样做时，拉取请求包括所有 5 个功能分支......不仅仅是分支“5”的提交。

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

Answer 1

我会按照以下步骤进行。

• 从开发创建的功能分支。
• 功能完成后将它们合并到开发分支。
• 当测试时间到来时，我将创建一个测试分支并在那里进行测试。我将修复在那里进行测试时出现的任何错误。
• 一旦我的测试全部成功，我将分支合并到 master 和 develop。
• 然后我会将我的代码从主环境发布到 Beta 环境。

我会记住以下几点。

• 如果特定版本不需要某个功能，我不会将该功能合并到 develo 分支。
• 如果我在测试时无法解决任何错误，我将不会发布该代码，因此在问题中我会解决所有错误并将发布整个代码。

Answer 2

您说将功能 5 合并到测试版中也会将功能 1-4 带入测试版。如果是这样，功能 1-4 的提交肯定在功能 5 分支中。有 3 种可能发生的方式：

1. 在功能 1-4 合并到开发后，功能 5 从开发中分支出来。

2. 在功能 1-4 合并到开发后，开发合并到功能 5（upmerge）。

3. 特征 1-4 直接合并到特征 5 中。

请注意，分支不仅包含直接提交到分支的提交，还包含从 repo 开始到分支点的所有提交，以及分支中的任何提交合并到分支中。

顺便说一句，即使您将 'merge' 更改为 'rebase' 或将 'develop' 更改为任何其他分支，上述 3 点仍然有效。

Answer 3

(3) 一旦新特性被测试/批准，就会在同一个特性分支中提出一个新的拉取请求；这个新的拉取请求旨在合并到“Beta”分支中。

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

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

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

• 每个新功能分支都是从另一个分支分支出来的。哪一个，发展？然后很明显，无论新创建功能的历史中的任何开发提交，也将合并到 beta 分支中。 Git 历史是一个有向无环图，每个提交指向一个（正常提交）或多个（合并提交）父提交。
• 为了使特性干净地合并到开发中，也许特性分支会定期重新基于开发，或者特性分支通过合并到最新的开发中来刷新，这两者都很有意义，我提倡。但在这种情况下，他们的历史也包含了合并/变基时的所有发展历史。

在每一种情况下，您的工作流程都被彻底破坏了，并且无法按照您的 beta 分支的想法工作。因此，如果您想避免摘樱桃（坏！坏！坏！），您如何才能实现您想做的事情？有一些基本选项：

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

Answer 4

你说得对，我们的工作流程不同于传统的 GitFlow。特征 分支完全独立地合并到 develop 或 beta 中。

测试/批准新功能后，会在同一功能分支中发出新的拉取请求

        f2--f2--f2   (f2)
       /          \
d--d--d--D1-------D2 (develop)
\       /
 f1---f1

一堆不需要/不相关的功能分支提交也被合并到“beta”中

奇怪：这就好像 f2 在 D2 合并提交上（它有 f2 也有 f1）。

为了测试，你可以在命令行中尝试cherry-pick the exact commits you want，然后merge them with --squash。

git checkout -b tmp develop
git cherry-pick  $(git merge-base develop f2) f2
git checkout beta
git merge --squash tmp

这样，您可以验证您在 beta 中只获得了您想要的确切 f2 合并分支，而不是所有其他功能。
一旦验证通过，我们就可以在 GUI 上做同样的事情（例如 SourceTree）

Answer 5

一旦您将一个分支与另一个分支合并，合并分支的提交就会在主分支上提交。

您可能想要做的甚至不是在 development 分支 上工作以进行开发，而是为每个功能（当然是序列化功能）分支出来，然后单独检查这些功能在将许多功能分支的包合并到开发分支之前的错误。

要消除进入开发分支的错误，您需要让代码在 feature 分支 上运行，然后合并该代码或通过恢复 feature 分支来恢复更改 使用git revert 然后再次合并分支（有效地只恢复它引入到开发分支的提交。

在行业中通常不建议在开发分支（或您的层次结构中的任何较大分支）上恢复，除非您只合并一个功能......因为不同的提交可以在它们之间建立依赖关系并且恢复可能导致弊大于利。

为了更好地恢复阅读this guide by atlassian 或available documentation。

Answer 6

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