Question

所以，我有一个类似于以下内容的场景：

A----B----C----D (master)
 \    \    \
  E-F--G--H-I (child)

在这种情况下，

C和D代表了大量的更改，包括大量重新排列目录树。 F和H要小得多，通常仅限于文件内容。 F，H或B中C和D中的各个文件的变化不大。所有这些修订都存在于共享的上游存储库中（因此，根据我的理解，编辑历史记录的任何内容都已存在）。

最简单的是，我最终会得到一个包含A, B, C, D, F和H的分支？

执行git checkout master; git merge child最终还原了C和D中进行的大量结构更改，我假设是因为它正在从合并提交中获取更改{{1 }和G。（I和C中重新定位的大量文件最终在工作树中两次。）

我可以在D和F上做一个挑选（虽然在我的例子中，它们代表了十几个提交 - 足以令人讨厌）。

理想情况下，我想要的是H选项。

我认为我不能git merge --ignore-merge-commits将孩子带到rebase，因为D已经在共享回购邮件中。

还有其他建议，还是我应该选择樱桃？

谢谢！