git - 我们可以在 git-flow 中将 develop 分支 merge 到 Feature 分支吗？

Question

1. 我们可以将 develop 分支 merge 到 git-flow 中的 feature 分支 吗？

2. 如下图所示，有两个功能分支(A(红色)和B(蓝色))，由两个开发人员分配。当B需要A的一些代码时，是否允许A push 开发继续编码，然后B 从开发中 pull 出来？

3. 一个merge develop分支，没有merge而是overwrite，为什么，如何解决？

Answer 1

1) 团队对此可能存在分歧，因为有些人认为“不必要的 merge ”让历史变得丑陋，但我认为将 develop merge 到功能分支中没有问题。如果您认为它可以使历史更清晰(并且尚未推送功能分支)，则另一种方法是将功能分支向前 rebase ，但这可能会破坏功能分支上的中间提交。

2) 不完整的特性不应 merge 到develop中。 develop 应该随时准备发布。在特性分支之间清晰地共享更改是很棘手的(而且，在具有小故事/特性的相当敏捷的方法中，通常是不必要的)。大多数方法都涉及一些妥协。见下文。

3) 我不确定您为什么会看到这种行为；可能需要有关您如何尝试 merge 的更多信息。您可以通过检查分支并执行类似 git reset --hard HEAD^

的操作来撤消 merge (最好是在没有推送 merge 的情况下完成)

---

好的，那么如果必须的话，如何共享代码呢？好吧，如果你接受我的建议不要将 A merge 到 develop 中，你可能会想“我可以将 A merge 到 B 直接？”。嗯，这比很快 merge 到 develop 更好，但这意味着 B 不能安全地 merge 到 develop 直到 A 是(因为它将携带 A 的部分实现)。

如果 A 还没有被推送，那么您可以对 A 进行交互式 rebase 以移动 B 所依赖的更改到 A 的开头，然后将 B rebase 到具有共同更改的提交上。但这可能涉及拆分提交，并且可能会创建中断的中间状态，并且取决于没有被推送的分支(或者每个人都必须从上游 rebase 中恢复)......这一切都不容易做到。

另一种选择是从 A 中挑选更改到 B 上。这也是一种 rebase 操作，但它保留所有现有的提交(所以不用担心是否已推送)。但是，如果共享的更改是在一个也有其他更改的提交中，这仍然不是那么容易；当将功能 merge 回 develop 时，它最终可能会导致冲突。

四面八方，最好尽可能避免这种情况。如果功能 B 依赖于功能 A，则可能会推迟功能 B，直到功能 A 已正确 merge 到 develop 或其他内容。