我应该等到子分支合并到主分支后再将Git孙子分支合并到主分支吗？

Question

在我的团队项目中，我正在一个从主分支(master)分支出来的功能分支(feature branch)上工作。我已经为功能分支(feature)发起了一个拉取请求(pull request)，目前正在进行审核，但在我能够合并之前还需要一段时间。

同时，我正在处理一些依赖于我在功能分支(feature)中实现的代码但与同一分支实际实现无关的事情。因此，我像这样分支出了一个新分支：

master
└── feature
    └── different_feature

如果我为different_feature提出一个拉取请求，并且在feature之前得到批准，我可以直接将其合并到master吗？还是说我应该等待将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分支中创建different_feature分支后，我进行了一些额外的提交。因此，different_feature只部分继承了在feature中进行的更新。

【更新】最终，我等待feature合并到master，然后重新将different_feature基于master进行变基，再将其合并到master中。这样可以将在feature和different_feature中所做的更新分开。

顺便说一下，当提出different_feature的拉取请求时，我发现您可以通过将请求的基本分支设置为feature而不是master来仅比较在此分支中所做的更改。但请确保在合并该拉取请求时将其改回master。

预先感谢。

- reesaspieces

Answer 1

在您描述的情况下（我添加了一些示例提交以便理解），“Original Answer”可以翻译成“最初的回答”。

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”。

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

然而，总体原则是相同的，如果您记得git基本上是在提交的基础上工作，而不是分支。

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

注：PR指Pull Request，提交代码请求。merge commit指合并提交。

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

different_feature > master的拉取请求将把D、E、F和G提交合并到master，如果先合并，第二个拉取请求将只剩下H和I需要合并，在第一个请求合并后会重新计算。

- Romain Valeri

---

感谢您的评论。实际上，我认为情况并非如此，因为在我从feature分支中分离出different_feature后，我一直在向其添加新的提交（根据我在feature拉取请求中收到的反馈进行了一些修改）。换句话说，different_feature继承了feature的一部分，但不是全部。 - reesaspieces

因此，以您的图表为例，在“feature”中的“D”和“E”之后有一些更新的提交。 - reesaspieces

谢谢。您已经完美地描述了情况。那么，回到我的最初问题 - 如果D和E是feature的一部分而不是different_feature的一部分，那么在合并I之前将G合并到主分支是否不可取？ - reesaspieces

@Risa 对于这个问题没有一个确定的答案，因为它最终取决于更改的性质。在复杂情况下，按照引入更改的时间顺序合并事物可能会更加简单，可以在合并feature之前合并different_feature，但在更简单的情况下，这也可能是一种不必要的限制。 - Romain Valeri

嗯，好的。我想我应该向我的团队询问这个特定的案例。我在这里提问是因为我想知道是否有任何针对这种情况的最佳实践被认可。谢谢！ - reesaspieces