问合并Git功能分支到"Beta“分支的问题(在它已经合并到”开发“分支之后)

EN

(3)一旦测试/批准了新特性，就会在相同的特性分支中生成一个新的拉取请求；这个新的拉取请求将被合并到“测试版”分支中。

“测试版”分支具有我们所有的“准备就绪”功能:实际上，我们将“测试版”分支直接发布到生产环境中，当准备就绪时，我们立即将“测试版”分支合并到“主”branch....by。

问题:在上面的步骤3中，当我们尝试将新的功能分支合并到'Beta‘分支中时，pull请求包括所有已经合并到'Develop’分支中的新提交。

不，这说不通。如果发生这种情况，您就忽略了一些重要信息，例如：

• 每个新功能分支都是从另一个分支分支而来的。哪一个，开发？那么很明显，无论开发提交是在新创建的功能的历史中，也将合并到测试版分支中。Git历史是一个有向无环图，每个提交指向一个(正常提交)或多个(合并提交)父提交。
• 为了使特性干净地合并到开发中，可能特性分支定期地重新建立到开发中，或者可能特性分支通过合并在最新的开发中刷新，这两种方法都很有意义，我提倡这样做。但在这种情况下，它们的历史也包含了merging/rebasing.

时代的所有开发历史

在每一种情况下，你的工作流程都会从根本上被破坏，无法根据你的测试版分支的想法来工作。因此，如果你想避免挑剔(坏！坏的!糟糕！)你如何才能实现你想要做的事情？有一些基本选项：

1. 功能切换:丑陋。只要有可能，我就会远离它。在任何分支中停用特性的最好方法是在该分支上首先没有相应的提交。
2. 干净利落地工作:很好。避免将未测试/未接受的特性合并回去进行开发。只有当它们被定义为done (如"definition of done")并被客户端接受时，才会合并它们。确保您设置了一个环境，使您的客户能够直接在功能分支上进行测试，而不是将其全部混合到beta分支上。通过这种方式，无论进行什么开发，都已经为生产做好了准备，并且您不再需要beta分支。未完成的工作永远不能合并到更高级别的分支中。这就是GitFlow的全部内容，并且它是有效的。即使你没有完全使用GitFlow，而只是使用了master、develop和feature分支，我的声明仍然有效。我在很多项目中都是这样工作的，效果很好。此外，如果你认为你需要另一个分支来为将来的版本集成特性，为它们创建一个新的"next_release“或" future”分支，并将它们合并到该分支，而不是develop。然后从开发中定期刷新未来，因为您还希望在未来版本中使用当前版本的功能，但反之亦然。不过，我几乎不认为这一额外的步骤是必要的。

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

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

您可能想要做的甚至不是在开发分支 for development上工作，而是为每个特性(当然，序列化特性)进行分支，然后在将许多特性分支的包合并到开发分支之前，分别检查这些特性是否有bug。

为了消除进入开发分支的bug，您将需要使代码在功能分支上工作，然后通过使用git revert恢复功能分支，然后再次合并分支(有效地仅恢复它引入到开发分支中的提交)来合并或恢复更改。

在行业中，恢复开发分支(或层次结构中任何较大的分支)通常是不明智的，除非您只合并一个功能……因为不同的提交可以在它们之间建立依赖关系，而恢复可能会造成比它解决的更多的危害。

要获得更好的恢复挂起，请阅读this guide by atlassian或available documentation。