git - 我应该等到 Git 孙子分支 merge 到 master 直到子分支 merge 到 master 吗？

Question

在我的团队项目中，我正在处理 feature从master.分支出来的分支我提出了 feature 的请求请求，它正在接受审查，但我还需要一段时间才能将其 merge 。

与此同时，我正在做一些依赖于我在 feature 中实现的代码的事情但不够相关，无法在同一分支中实际实现。所以我分支了feature ，像这样:

master
└── feature
    └── different_feature

如果我为 different_feature 提出 pull 请求并在 feature 之前获得批准，我可以简单地将它 merge 到 master 吗？ ？或者我应该等待 merge different_feature直到 feature merge 到 master ？

我对第一个选项的担心是，稍后当您检查日志时，feature 的某些部分将 merge 到 master在 fghij , 实际上它应该 merge 到 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 做了一些额外的 promise 。在我分支之后 different_feature从中。所以different_feature仅部分继承了 feature. 中所做的更新

[更新] 最后，我等到feature merge 到master , 然后重新定位 different_feature到 master在 merge 到 master 之前以及。这使我能够将 feature 中完成的更新分开与在 different_feature 中完成的相比.

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

Answer 1

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

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

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

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

此外，需要注意的是，没有什么能阻止您在稍后不还原 F 的情况下还原 feature 提交(D 和 E)和 G，前提是您在 merge 期间不压缩提交。

---

评论后编辑

实际情况好像更像

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

但总体原则是相同的，如果您还记得 git 从根本上是基于提交而不是分支工作的话。

第一次PR后的情况(J为merge commit)

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

different_feature > master pull 请求将带来 D、E、F 和 G 提交到 master，如果先 merge ，它只会让 H 和 I 留在第二个 pull request 中 merge , 将在第一个 merge 后重新计算。