将Git Feature分支合并到“Beta”分支（已合并到“Develop”分支后）问题

我们有一个标准Web项目并为此项目维护3个核心分支：Master，Beta和Develop。以下是我们使用的流程/工作流程摘要：将Git Feature分支合并到“Beta”分支（已合并到“Develop”分支后）问题

（1）请求新功能/更新，以便我们创建新功能分支。

（2）为新的Feature分支提交提交，并将Feature分支合并到'Develop'分支;然后将'Develop'分支发布到测试环境进行测试。（3）一旦新功能被测试/批准，新的拉取请求将在同一个功能分支中进行;这个新的pull请求将被合并到'Beta'分支中。 'Beta'分支具有我们所有的“随时可用”功能：事实上，我们直接将“Beta”分支发布到生产环境，当准备就绪时，我们立即将“测试版” '分支到'主'分支......通过这样做，'主'分支始终是生产环境中代码的副本。

问题：在上面的第3步中，当我们试图将新的Feature分支合并到'Beta'分支时，该请求包含所有已经合并到'Develop'分支中的新提交。

示例：5个特征分支单独合并到'Develop'分支（分支标记为1,2,3,4和5）。所有5个都经过了测试，但是前4个有bug。所以分支“5”被批准，我们试图为该Feature分支创建一个拉取请求，并将它合并到'Beta'....但是当我们这样做时，该拉请求包括全部5个特征分支....不仅仅是分支“5”的提交。

我们必须做错了！我们可以做些什么来解决我们的流程/工作流程？

来源

2016-11-14 Kris

的可能的复制[待办事项Git的合并影响 “合并” 分支？]（http://stackoverflow.com/questions/40466290/do-git-merges-affect-the-merged-branch） –

哪个分支你测试了吗？不同的功能彼此干扰的频率如何？ – oyvind

我问的原因是因为它看起来像只在一个分支上进行测试（开发），但是您仍然能够独立地测试/批准更改。所以我猜猜这些功能通常不会相交。 – oyvind

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

来源

2016-11-14 17:38:19

来自OP公司的员工：我们确实为每个功能创建了独立的分支，因为这是GitFlow的完整基础。功能是从“开发”分支创建的，如果我们需要在测试版网站上进行这些更改，那么它们将从其中合并回“开发”，并且还会转换为“测试版”。 –

传统将决定合并功能分支以“开发”，然后在准备好时将“开发”合并为“测试版”，但这对我们不起作用。客户端有时需要选择性地测试新功能，而不使用该站点的最前沿版本，这是现有测试版分支的要点。它基本上是一个较低版本的“开发”版本，但它是合并到官方版本的主版本。 –

我们的问题是，有时，试图在已将特征合并到“开发”之后尝试将特征合并到“测试版”中时，将包括不应包含在特征分支中的几个不相关的提交，因为既不是开发版，测试版或主人应该被合并到一个功能。我们只需要弄清楚什么地方出了问题，这样我们就可以让我们的团队在将来不会犯同样的错误。 –

一旦你合并与另一个分支，合并分支提交得到承诺在主分支。

你可能想要做的是不是即使在开发分支进行开发工作，而是另辟蹊径的它然后将它们分别合并前检查错误每个功能（序列化功能，当然）什么许多功能包的分支进入开发分支。

为了摆脱钻进开发分支的bug反正你将需要得到工作的特性分支代码，然后归并或使用git revert恢复的特性分支，然后合并恢复更改（有效地还原仅提交给开发分支的提交

在开发分支（或层次结构中的任何更大的分支）上恢复通常在业界不受欢迎，除非您合并只是一个功能......因为不同的提交可以建立依赖关系b他们自己和回复会造成更多的伤害，而不是解决问题。

为了获得更好的回复读取this guide by atlassian或available documentation。

来源

2016-11-14 18:02:41

嗨，我和OP一样在同一个团队中 - 我们正在完成从“开发”分支创建的各个功能分支的所有工作，然后在完成时将其合并回“开发”。这些功能分支有时也会合并到“测试”分支，以定期部署到测试版服务器。最后，只要准备就绪，“测试版”就会定期合并到主分支。 –

这个工作流程应该可以正常工作，但由于某种原因，无论何时我们试图将我们的功能分支合并到“测试版”（在他们已经被合并为“开发”之后），一堆不需要/不相关的功能分支提交被合并到“测试版”以及。我们需要弄清楚发生了什么问题，因此我们可以将功能分支完全独立于“开发”和“测试”。 –

我不确定我是否理解......您正在将功能分支合并到测试版分支中？在开发分支设置好后，你应该： 'checkout beta'，'merge development'，并且分支被合并。如果你完全搞砸了开发分支，垃圾提交被埋在其他提交下面......你想做什么，除非你准备['樱桃']（https://git-scm.com/ docs/git-cherry-pick），将删除开发分支，并从工作测试版再次分支出来。我认为这是一个学校项目的种类？如果是这样，请不要挑选 –

你是对的，我们的工作流程与传统的GitFlow不同。特征分支完全独立地合并为EITHER develop或beta。

一旦新功能进行测试/批准，新拉请求同一个要素分支

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

不需要的/不相关的特性分支提交的一堆合并为“测试版”制作以及

奇怪：这就好像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

这样的话，你可以验证你只会让你处于测试阶段所需的准确f2合并分支，不是所有的其他功能。
一旦通过验证，我们可以从一个GUI（例如像SourceTree）做同样的工作

来源

2017-02-26 21:53:43 VonC

（3）一旦新功能进行测试/批准，新拉请求在同一制造特色分支;这个新的pull请求将被合并到'Beta'分支中。 'Beta'分支具有我们所有的“随时可用”功能：事实上，我们直接将“Beta”分支发布到生产环境，当准备就绪时，我们立即将“测试版” '分支到'主'分支......通过这样做，'主'分支始终是生产环境中代码的副本。

问题：在上面的第3步中，当我们试图将新的Feature分支合并到'Beta'分支时，该请求包含所有已经合并到'Develop'分支中的新提交。

不，这没有意义。如果发生这种情况，您省略了重要信息，例如：

每个新功能分支都从另一个分支分支出来。哪一个，发展？那么很明显，无论开发提交是在新创建的特性的历史中，还将被合并到测试版分支中。 Git历史是一个有向非循环图，每个提交指向一个（正常提交）或多个（合并提交）父提交。
为了使特性融合得到干净的发展，也许特性分支定期重新开发，或者通过合并最新开发来更新特性分支，这两者都很有意义，我提倡它。但在这种情况下，他们的历史也包含了合并/重组时的所有发展历史。

在每种情况下您的工作流程是从根本上打破，不能关于你的一个beta分支的思想工作。所以如果你想避免樱桃采摘（坏的！坏的！坏的！）你怎么能达到你想要的？有一些基本的选项：

功能切换：丑陋。只要有可能，我会远离它。在任何分支中取消激活功能的最佳方法是首先不在该分支上进行相应的提交。
工作干净：很好。避免合并未经测试/未接受的功能进行开发。只有当它们是完成（如在“完成的定义”中）并且被客户接受时才合并它们。确保你设置了一个环境，使你的客户可以直接测试功能分支，而不是将它们全部混合到测试版分支上。通过这种方式，无论发展如何，本质上都是为生产做好准备，而且您不再需要beta分支。未完成的工作永远不会被合并到更高层次的分支中。这就是GitFlow的全部内容，它的工作原理。即使你没有充分利用GitFlow，但只是掌握，开发和设计分支，我的陈述的有效性就成立了。我在许多项目中都是这样工作的，而且工作起来非常漂亮。此外，如果您认为您需要另一个分支来将功能集成到未来版本中，请为他们创建一个新的“next_release”或“future”分支，并将它们合并到该分支，而不是开发。然后定期从开发中刷新未来，因为您还希望在未来版本中使用当前版本的功能，但反之亦然。我几乎不相信这个额外的步骤将是必要的。

来源

2017-02-26 23:10:32 kriegaex

Keith Pickering对另一个答案的评论表明，功能分支是从'develop'分支创建的。我认为你的第一个要点是发现。 – mkasberg

对不起，我还没有彻底阅读其他答案。 – kriegaex

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

特征5从特征1-4被合并为展开后从展开分支出来。
在特征1-4合并为开发后，开发被合并到特征5（上行）中。
特点1-4直接并入功能5.

谨防分支不仅包含直接向分公司提交，而且全部来自回购之初到提交分支点和分支中的任何提交合并到分支中。

顺便说一下，即使您将“合并”更改为“rebase”或“develop”到任何其他分支，以上3点仍然成立。

来源

2017-03-03 00:27:18 oyvind

我会做下面的步骤。

从开发创建的功能分支。
一旦功能完成合并它们开发分支。
当测试的时间到了，我会创建一个测试分支并在那里做测试。我会修复那些在测试中出现的错误。
一旦我的测试都取得成功，我将分支合并到master和develop中。
然后，我会将我的代码从主环境释放到Beta环境。

我会记住下列事情。

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

来源

2017-03-05 10:55:00

将Git Feature分支合并到“Beta”分支（已合并到“Develop”分支后）问题

回答

相关问题