为什么Git子树不使用rebase？

Question

我使用git subtree add向我的项目添加了另一个repo，现在当我使用git subtree pull --prefix=subtree-dir subtree-origin subtree-branch --squash从子树项目更新我的主项目时，我的主要历史记录中会出现两个新提交，前者说“Squashed 'subtree-dir/' changes from 618c8ff..822004d”，后者是引用前者的合并提交。

这感觉很不好。

我知道挤压提交是必要的（否则来自子树项目的所有中间提交都会被包含），但是否有任何方法可以避免第二个合并提交？我希望能发现一种类似于git pull --rebase的行为模式。

如果你今天还没有听到过，你太棒了。

- cameronboehmer

---

为什么这很恶心？记录的这两个操作发生了：首先，子树被更新（压缩合并），然后您的主分支被更新（子树的合并）。为什么您要不惜一切代价避免第二个合并提交？毕竟，它确实携带着发生的信息。 - Sigi

当然，你是对的。这感觉很糟糕，因为父项目中的大部分工作都是在子项目中完成的，所以历史记录只是一系列压缩/合并提交。我更喜欢它表现得像一个快进式合并，没有合并提交，因为这些合并并不是非常有意义的。 - cameronboehmer

Answer 1

首先，你是正确的... Git subtree 在最佳情况下创建一个压缩提交，没有祖先（内容来自不同的远程/存储库）和一个常规的合并提交。

Git subtree 没有提供 --rebase 选项。它不在 源代码中。Git subtree 总是使用 git merge 来集成更改。具体来说，它使用 子树合并策略（我肯定是受到了子命令名称的启发）来使子目录“魔法”和不相关的历史记录正常工作。

（更多关于“不相关历史记录”的信息请参见：https://dev59.com/ploU5IYBdhLWcg3wAjYs#37938036）

我认为 rebase 不理解子树合并策略，因此将其用于集成更改简单地是一个不恰当的选择。

- Anthony Mastrean