为什么 Git 子树不使用 rebase？答案

【问题标题】：Why doesn't Git subtree use rebase?为什么 Git 子树不使用 rebase？
【发布时间】：2014-03-17 05:09:17
【问题描述】：

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

这感觉很恶心。

我知道 squash 提交是必要的（或者子树项目中的所有干预提交），但是有什么方法可以避免第二次合并提交？我很想发现一种行为类似于git pull --rebase 的模式。

如果您今天还没有听说过，那您真是太棒了。

【问题讨论】：

为什么这么恶心？记录的这两个操作发生了：首先，子树被更新（压缩合并），然后你的主分支被更新（子树的合并）。为什么要不惜一切代价避免第二次合并提交？毕竟，它确实包含有关发生的事情的信息。
当然，你是对的。感觉很恶心，因为父项目中的大部分工作都包含子项目中的工作，所以历史只是一系列 squash/merge 提交。我希望它表现得像一个没有合并提交的快进合并，因为合并不是很有意义。

标签： git git-subtree

【解决方案1】：

首先，你是对的...... Git 子树最多创建一个没有祖先的压缩提交（内容来自不同的远程/存储库）和一个常规合并提交。

Git 子树不提供--rebase 选项。它不在source code 中。 Git 子树总是使用git merge 来集成更改。具体来说，它使用subtree merge strategy（我敢肯定，它激发了子命令名称）使子目录“神奇”和不相关的历史正常运行。

（更多关于“无关历史”的信息：https://stackoverflow.com/a/37938036/3619）

我不认为 rebase 理解子树合并策略，因此它只是集成更改的不合适选择。

【讨论】：