将Git功能分支合并到“Beta”分支时出现问题（在已将其合并到“Develop”分支之后）

Question

我们有一个标准的Web项目，维护着这个项目的三个核心分支：主分支（Master）、测试分支（Beta）和开发分支（Develop）。以下是我们使用的流程/工作流总结：

(1) 需要新增功能/更新时，我们会创建一个新的Feature分支。

(2) 在该Feature分支上做出提交，并将该Feature分支合并到“开发”分支中；然后将“开发”分支发布到测试环境进行测试。

(3) 一旦新功能通过了测试/审批，就会在同一Feature分支上创建一个新的拉取请求；此新拉取请求旨在合并到“测试”分支中。

“测试”分支拥有我们所有“即将上线”的功能：实际上，我们直接将“测试”分支发布到生产环境中，当准备好之后，立即将“测试”分支合并到“主”分支中...通过这样做，“主”分支始终是生产环境中代码的副本。

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

例如：5个特性分支被单独合并到“开发”分支中（分支编号为1、2、3、4和5）。所有5个分支都经过了测试，但前4个存在漏洞。因此，分支“5”得到了批准，我们试图为该Feature分支创建一个拉取请求，并将其合并到“测试”中...但是当我们这样做时，拉取请求包括所有5个特性分支...而不仅仅是分支“5”的提交。

我们一定做错了！我们该如何修复我们的流程/工作流？

- Kris

---

可能是Do Git merges affect the "merged" branch?的重复问题。 - David Lipnik

你测试哪些分支？不同特性之间的干扰频率有多高？ - oyvind

我问的原因是因为你似乎只在一个分支（develop）上进行测试，但你仍然能够独立地测试/批准更改。所以我猜想这些功能不经常相互交叉。 - oyvind

Answer 1

（3）一旦新功能经过测试/审核，就会在同一功能分支中创建新的拉取请求；这个新的拉取请求是要合并到' Beta '分支中的。

' Beta '分支有我们所有"准备上线的"功能：实际上，我们直接将' Beta '分支发布到生产环境中，当准备就绪时，我们立即将' Beta '分支合并到' Master '分支中......这样，' Master '分支始终是生产环境代码的副本。

问题在于：在步骤3中，当我们尝试将新的功能分支合并到' Beta '分支中时，拉取请求包括已合并到' Develop '分支中的所有新提交。

1. 特性开关：丑陋。只要可能，我会尽量避免使用它。在任何分支中关闭一个特性的最好方式是一开始就不在该分支上提交对应的提交。
2. 工作清晰：好。避免将未经测试或未被客户接受的特性合并回开发分支。只有当它们达到了“完成”（即“定义为已完成”）并被客户接受后，才能将它们合并。确保设置一个环境，使您的客户可以直接在功能分支上进行测试，而不是将所有内容都混淆到beta分支上。这样，无论什么进入开发阶段，本质上都准备好了生产，您不再需要beta分支。未完成的工作永远不应该合并到更高级别的分支中。这就是GitFlow的全部内容，它很有效。即使您没有完全使用GitFlow，只是使用主分支、开发分支和功能分支，我的说法也是正确的。我在许多项目中都是这样工作的，效果非常好。此外，如果您认为需要另一个分支来集成未来发布的特性，请为它们创建一个新的“next_release”或“future”分支，并将它们合并到该分支，而不是合并到开发分支。然后定期从开发分支刷新future，因为您还希望将当前发布的特性放入未来的发布中，但反过来则不然。我几乎不相信这个额外的步骤会是必要的。

- kriegaex

---

Keith Pickering 的另一个回答中提到，功能分支是从 develop 分支创建的。我认为你的第一个要点很准确。 - mkasberg

Answer 2

您说得对，我们的工作流与传统的GitFlow不同。功能分支被合并到develop或beta中的任一一个，完全独立于其他分支。

一旦新功能经过测试/批准，在相同的功能分支中创建新的拉取请求。

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

一堆不需要或无关的特性分支提交也被合并到“beta”中了。

奇怪：这就好像f2在D2合并提交中（其中有f2但也有f1）一样。

为了测试，请尝试在命令行中 挑选你想要的确切提交，然后 使用--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）执行相同操作。

- VonC

Answer 3

你说将功能5合并到beta中将使功能1-4也进入beta。如果是这样，那么功能1-4的提交肯定在功能5的分支中。这可能有3种方式：

1. 功能5是从开发中分支出来的，在将功能1-4合并到开发之后。
2. 在将功能1-4合并到开发之后，将开发合并到了功能5中（向上合并）。
3. 将功能1-4直接合并到了功能5中。

请注意，一个分支不仅包含直接提交到该分支的提交，还包括从存储库开始的所有提交，以及合并到该分支的任何分支中的提交。

顺便说一句，即使您将“合并”更改为“变基”，或将“开发”更改为任何其他分支，上述3点仍然适用。

- oyvind

Answer 4

我将执行以下步骤：

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

我会记住以下几点：

• 如果某个特性不需要发布，我就不会将该特性合并到develop分支。
• 如果在测试过程中无法解决任何错误，我就不会发布该代码，因此如题所述，我会解决所有错误并发布整个代码。

- jones j alapat

Answer 5

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

- Giacomo

---

来自OP公司的员工在此：我们确实为每个功能创建单独的分支，因为这是GitFlow的整个基础。功能是从“develop”分支创建的，然后将它们合并回“develop”，如果我们需要在beta网站上进行更改，则还会合并到“beta”中。 - Keith Pickering

传统上，合并功能分支到“develop”是一种惯例，然后在准备好时将“develop”合并到“beta”，但这对我们来说不起作用。客户有时需要有选择性地测试新功能，而不使用最尖端版本的网站，这就是beta分支存在的意义。它基本上是“develop”的一个不那么最新的版本，但它是合并到主分支以进行正式发布的版本。 - Keith Pickering

我们的问题是，有时在将功能合并回“develop”后尝试将其合并到“beta”中，会包括几个不相关的提交，这些提交不应该包含在功能分支中，因为 develop、beta 或 master 永远不应该合并到功能分支中。我们只需要找出问题出在哪里，这样我们就可以防止团队在未来犯同样的错误。 - Keith Pickering

抱歉打扰，但是很抱歉，您没有正确使用Git。您想要实现的目标可以通过其他方式轻松实现。这是一个曾经作为Scrum和Git教练指导过许多开发团队的人说的话，我的团队从未使用过如此扭曲的分支/合并工作流程。相信我，您不是世界上最复杂的需求。 - kriegaex

Answer 6

一旦你将一个分支与另一个分支合并，合并的分支提交记录就会被提交到主分支上。

你可能想做的是不要在开发分支上进行开发工作，而是从中分支出每个功能分支（当然要对这些功能进行序列化），然后单独检查这些功能分支上的错误，然后将许多功能分支打包合并到开发分支中。

为了摆脱那些已经进入开发分支的bug，你需要让代码在功能分支上运行，并进行合并，或使用git revert撤销功能分支的更改，然后再次合并该分支（有效地只撤销了它引入到开发分支中的提交）。

在业界中，通常不建议在开发分支（或任何较大的分支）上撤销操作，除非你只合并了一个单独的功能，因为不同的提交之间可能会建立依赖关系，撤销操作可能会引起更多的问题。

为了更好地掌握还原，请阅读Atlassian的指南或可用文档。

- David Lipnik

---

嗨，我和OP在同一个团队 - 我们在各自的功能分支上进行所有工作，这些分支是从“develop”分支创建的，完成后再合并回“develop”。这些功能分支有时也会合并到“beta”分支，以便定期部署到beta服务器。最后，“beta”定期合并到主分支，以便随时准备上线。 - Keith Pickering

这个工作流程应该是正常的，但出于某种原因，每当我们尝试将我们的特性分支合并到“beta”（在它们已经合并到“develop”之后），一堆不需要或无关的特性分支提交也会被合并到“beta”。我们需要找出问题出在哪里，以便能够完全独立地将特性分支合并到“develop”和“beta”。 - Keith Pickering

我不确定我理解了...你要将特性分支合并到beta分支中？当开发分支设置好后，你需要执行以下操作： checkout beta，merge development，然后分支就会合并。如果你完全搞砸了开发分支，并且有一些被其他提交淹没的垃圾提交...除非你准备好'cherrypick'，否则你需要删除开发分支，并从工作中的beta再次创建一个新分支。我猜这是某种学校项目？如果是这样，请不要使用cherry-pick。 - David Lipnik

因此，develop分支用作代码的最新版本，我们从中创建所有新功能分支。这些功能分支在完成时总是合并回develop，但当它们准备好进行测试时，我们也将它们逐个合并到beta分支中。如果客户对更新满意，则将beta合并到master中。 - Keith Pickering

我们的问题在于我们很难理解git历史记录（无论是可视化还是非可视化），因此我们无法弄清楚为什么将某些功能合并到beta之后，这些功能已经被合并回develop，但有时会包含不应该出现在该特定功能分支上的不需要的功能。我们需要知道这样的错误可能如何发生，以便我们可以知道在提交历史记录中要查找什么。 - Keith Pickering