我们能否在git-flow中将develop分支合并到Feature分支中？

Question

1. 在git-flow中，我们可以将develop分支合并到feature分支吗？

2. 如下图所示，有两个特性分支(A(红色)和B(蓝色))，由两个开发人员负责。当B需要A的一些代码时，是否允许A将代码推送到develop继续编码，然后B从develop拉取它？

3. 合并develop分支时，实际上是覆盖而不是合并，为什么，以及如何解决？

- 王岩华

Answer 1

1) 团队对此可能有不同的看法，因为一些人认为“不必要的合并”会使历史记录变得混乱，但是我认为将develop合并到特性分支中没有问题。如果您认为这样可以使历史记录更加清晰（并且还没有推送功能分支），则另一种选择是将特性分支向前变基，但这可能会破坏特性分支上的中间提交。

2) 不应将不完整的功能合并到develop 中 。develop应随时准备好发布。在特性分支之间清晰地共享更改很棘手（并且在合理的敏捷方法论和小故事/特性中通常是不必要的）。大多数做法都需要一些妥协。见下文。

3) 我不确定您为什么会看到那种行为；可能需要更多信息来了解您如何尝试合并。您可以通过检出分支并执行类似于 git reset --hard HEAD^ 的操作来撤消合并（最好在合并未推送的情况下进行）。

---

好吧，如果您不得不共享代码，该怎么办？嗯，如果你听从我的建议，不要将A合并到develop，而是可以考虑“我能否直接将A合并到B？”。嗯，这比太快地合并到develop要好，但意味着在A已经实现之前，B不能安全地合并到develop中（因为它将携带A的部分实现）。

如果A尚未推送，则可以进行交互式变基，将B依赖于的更改移动到A的开头，然后将B变基到具有公共更改的提交上。但这可能涉及拆分提交，并可能创建损坏的中间状态，也取决于分支是否已被推送（或每个人都必须从上游重置）…总体来说不容易做到。

另一个选择是从A复制更改到B。这也是一种重新定位操作，但它使所有现有提交保持不变（因此无需担心事情是否已被推送）。但是，如果共享的更改位于还有其他更改的提交中，这仍然不太容易；并且最终合并功能回到develop时可能会导致冲突。

总而言之，最好尽可能避免这种情况。如果功能B依赖于功能A，则可以暂停功能B的开发，直至将功能A正确合并到develop或其他地方为止。

- Mark Adelsberger

---

非常感谢，最好的问候！ - 王岩华

我有一个问题。每次当前正在更新的功能分支被更新时，将develop合并到该分支是一种好的实践吗？例如：我们有三个功能分支：Feature1、Feature2、Feature3我们有默认的develop分支。当Feature1将其更改合并到develop时，我应该立即将develop合并到Feature2和Feature3中，以避免新代码出现错误，并始终在分支中拥有最新的代码版本吗？提前致谢！ - rihhot

@rihhot：没有通用的“正确”或“错误”工作流程。在gitflow中不推荐这种做法。 - Mark Adelsberger

@MarkAdelsberger 谢谢你的回答。我还在学习，所以这个帮助对我来说非常宝贵。 - rihhot