我是否应该等到子分支合并到主分支后才将 Git 孙分支合并到主分支？

Question

在我的团队项目中，我正在开发一个从 master. 分支出来的 feature 分支合并它。

同时，我正在处理一些依赖于我在feature 中实现的代码但相关性不足以在同一分支中实际实现的东西。所以我从feature 分支出来，像这样：

master
└── feature
    └── different_feature

如果我对different_feature 提出拉取请求并且在feature 之前获得批准，我可以简单地将其合并到master 吗？还是我应该等到 different_feature 合并到 master 后再合并 different_feature？

我对第一个选项的担忧是，稍后当您检查日志时，feature 的某些部分将在fghij 中合并到master，而实际上它应该在abcde 中合并。如果我们想保留 different_feature 而摆脱 feature（回滚），这可能会很不方便。

git log (from newest to oldest - with dummy commit hashes)

abcde Merge pull request: feature
fghij Merge pull request: different_feature
klmno Merge pull request: something_implemented_before_all_this

提前致谢。

[编辑] 忘了提及这一点：在我从 feature 分支之后，我对 feature 做了一些额外的提交。所以different_feature 只是部分继承了feature. 中所做的更新

[更新] 最终，我等到feature 合并到master，然后将different_feature 重新定位到master，然后再将其合并到master。这让我可以将feature 中完成的更新与different_feature 中完成的更新区分开来。

作为旁注，当提出 different_feature 的拉取请求时，我了解到您可以通过将请求的基本分支设置为 feature 而不是 master 来仅比较您在此分支中所做的更改.只需确保在合并该拉取请求时将其更改回 master。

Answer 1

在您描述的情况下（我添加了一些示例提交以进行推理）

A---B---C <<< master
         \
          D---E <<< feature
               \
                F---G <<< different_feature

feature > master 的拉取请求只会带来D 和E 的提交，但different_feature > master 的另一个拉取请求会带来D、E、F 和G。

如果您在different_feature > master 已经被接受/合并之后尝试拉取请求feature > master，则将没有任何东西可以合并，这将导致无操作。

另外，需要注意的是，没有什么可以阻止您在稍后恢复 feature 提交（D 和 E）而不恢复 F 和 G，只要您在合并。

---

在 cmets 之后编辑

实际情况好像更像

A---B---C <<< master
         \
          D---E---H---I <<< feature
               \
                F---G <<< different_feature

但总体原理是一样的，如果你还记得 git 基本上是基于提交而不是分支工作的话。

第一次 PR 后的情况（J 是合并提交）

A---B---C---------------J <<< master
         \             /
          D---E---F---G <<< different_feature
               \
                H---I <<< feature

different_feature > master 拉取请求会将D、E、F 和G 提交到master，如果先合并，它只会让H 和I 离开在第二个 pull request 中合并，第一个合并后会重新计算。