我们可以将开发分支合并到git-flow中的Feature分支中吗？

Question

1. ，我们可以将其合并开发分支到特性分支在混帐流？

2. 如下图所示，有两个功能分支（A（红色）和B（蓝色）），由两位开发人员分配。当B需要A的部分代码时，是否允许那A推开发进行编码，然后B把它从开发？

3. 合并开发分支，它没有合并，但覆盖，为什么，以及如何解决它？

Answer 1

1）参赛队可以在此不同的一些认为“不必要合并”创造历史很丑，可是我看到合并develop到功能分支没有问题。如果您认为它使历史更清晰（并且尚未推送功能分支），则可以选择将功能分支向前重新绑定，但这可能会中断功能分支上的中间提交。

2）不完整的功能不应合并到develop。 develop应随时准备发布。干净地在功能分支之间共享变化是非常棘手的（并且，对于具有小故事/功能的合理灵活的方法，通常是不必要的）。大多数做法都涉及到一些妥协。见下文。

3）我不确定为什么你会看到这种行为;可能需要有关您如何尝试合并的更多信息。通过检查出来的分支，做一些像git reset --hard HEAD^

---

好了，所以如何，如果你有共享代码（如果这是在没有已被推合并完成最好的），您可以撤消合并？那么，如果你接受我的建议，不要将A合并到develop，你可能会认为“我可以直接合并A到B？”。那么，这比直接合并到develop好，但意味着B不能安全地合并到develop，直到A已被（因为它将进行部分实施A）。

如果A没有被按下，那么你可能会做的A一个互动变基到移动上B取决于高达A开始的更改，然后重订B到有共同变化的提交。但这可能涉及到分割提交，并可能创建中断状态，并取决于没有被推动的分支（或者每个人都必须从上游转账中恢复）......所有这些都不容易做到。

另一种选择是从A挑选到B的变化。这也是一种重新绑定操作，但它保留了所有现有的提交（因此不必担心是否推送了任何内容）。但是，如果共享变更处于也存在其他变更的提交中，它仍然不是那么容易;当将这些功能合并回develop时，最终可能会导致冲突。

四处都是，只要有可能就避免这种情况。如果功能B取决于功能A，则可以在功能B上保持关闭状态，直到功能A正确合并为develop或其他。