如何用git subtree split缓存已处理历史？实现增量提交拆分？

嘿，这个问题戳中了git subtree split的一个默认痛点——每次默认都会从头遍历整个提交历史，仓库提交多了简直慢到让人抓狂。不过别担心，咱们有办法让它只处理新增的提交，实现增量执行。

核心思路是利用git subtree split的--onto参数，结合提交范围限定，让Git基于上一次split的结果继续处理后续提交。具体步骤如下：

1. 先记录上一次split的基础 #

假设你第一次执行split时，已经把commit1到commit3的子目录内容拆分到了一个分支（比如叫split-branch），执行命令大概是：

git subtree split -P <你的子目录路径> -b split-branch

此时split-branch的HEAD就是commit3对应的拆分后提交，一定要保留这个分支（或者记下它的commit哈希），这是增量的基础。

2. 增量执行split #

当新增commit4后，执行下面的命令，让Git只处理commit3到commit4的变化：

git subtree split -P <你的子目录路径> --onto split-branch commit3..master -b split-branch

咱们拆解下关键参数：

• --onto split-branch：告诉Git，新的拆分提交要基于上一次拆分好的分支（也就是commit3对应的拆分结果）来生成，不用从头开始
• commit3..master：明确限定只处理从commit3（上一次拆分的最后一个原仓库提交）到当前master（commit4）的提交范围
• -b split-branch：更新原有的拆分分支，把新增的拆分提交追加进去（如果想用新分支也可以换个名字）

如果之前没保存分支，只记得上一次拆分后的commit哈希（比如abc123），也可以直接用哈希代替分支名：

git subtree split -P <你的子目录路径> --onto abc123 commit3..master -b split-branch

注意事项 #

• 必须保证commit3确实是上一次拆分时覆盖的最后一个原仓库提交，不然可能会出现重复处理或者冲突
• 不要删除上一次的拆分分支/提交哈希，否则就只能从头开始遍历了
• 如果子目录路径有变化，要确保和第一次split时的路径一致，不然会出错

这样操作后，Git就会跳过commit1到commit3的遍历，直接从commit3开始处理新增的commit4，效率会提升很多。

内容的提问来源于stack exchange，提问作者Phương Nguyễn