我们可以将 develop 分支 合并到 git-flow 中的 feature 分支 吗？
如下图所示，有 2 个功能分支（A(red) 和 B(blue)），由两个开发人员分配。当B 需要来自A 的一些代码时，是否允许 A 推送到开发继续编码，然后B 从开发中提取它？
合并开发分支，没有合并而是覆盖，为什么，如何解决？
【问题讨论】：
标签： git github merge workflow git-flow
1) 团队可能对此有所不同，因为有些人认为“不必要的合并”会使历史变得丑陋，但我认为将 develop 合并到功能分支中没有问题。如果您认为它使历史更清晰（并且尚未推送功能分支），另一种选择是向前重新设置功能分支，但这可能会破坏功能分支上的中间提交。
2) 不完整的功能不应合并到develop。 develop 应该随时可以发布。在功能分支之间干净地共享更改是棘手的（并且，在具有小故事/功能的合理敏捷方法中，通常是不必要的）。大多数方法都涉及一些妥协。见下文。
3) 我不确定您为什么会看到这种行为；可能需要有关您如何尝试合并的更多信息。您可以通过检查分支并执行类似git reset --hard HEAD^
好的，那么如果需要，如何共享代码？好吧，如果您接受我的建议不要将A 合并到develop，您可能会想“我可以直接将A 合并到B 吗？”。好吧，这比很快合并到develop 要好，但这意味着在A 之前，B 不能安全地合并到develop（因为它会包含A 的部分实现）。
如果A 尚未被推送，那么您可以对A 进行交互式变基，以将B 所依赖的更改移动到A 的开头，然后将B 变基到具有共同更改的提交。但这可能涉及拆分提交，并可能创建中断的中间状态，并且取决于尚未推送的分支（或者每个人都必须从上游 rebase 中恢复）......这一切都不容易做到。
另一种选择是从A 到B 中挑选更改。这也是一种变基操作，但它使所有现有的提交保持原样（所以不用担心事情是否已被推送）。但是，如果共享更改在一个也有其他更改的提交中，这仍然不是那么容易；并且在将功能合并回develop时可能最终会导致冲突。
到处都是，最好尽可能避免这种情况。如果功能 B 依赖于功能 A，则可能会推迟功能 B，直到功能 A 正确合并到 develop 或其他东西。
【讨论】：