我一直在使用git子树扩展名（https://github.com/apenwarr/git-subtree）。 我使用“--squash”来使主项目的日志变得干净，我的步骤如下：
将lib添加到主项目中
git subtree add -P sub / libdir --squash lib_remote master
从lib获取更新
git subtree pull -P sub / libdir --squash lib_remote master
将更改推送到lib_remote
git subree push -P sub / libdir --squash lib_remote master
它对我来说非常好（主要项目和lib，有一个历史很有意义）。问题是git子树推送的时间越来越长。
我使用git-subtree的目的与Screndib几乎相同，后者问道 git-subtree is not retaining history so I cannot push subtree changes, how can I fix this/avoid this issue in the future?
我想，当使用--squash时，每次处理推送时，git子树需要搜索自“子树添加”以来的整个历史记录。
如何减少子树推送的时间？或者让它更有效，而不是整个历史，只是自上次git子树推送（或拉动）以来的过程变化？
答案 0 :(得分：4)
我假设代码中的“lib_remote”是远程lib repo的url而不是当前仓库中的分支？当前仓库中的远程仓库URL和分支都在工作。
我发现您使用git subtree add将远程库添加为子树，然后使用git subtree push推送更改。
最好做一个git subtree split操作，在推送操作之前将子树更改拆分为一个单独的分支，然后将拆分的分支推送到远程仓库并保持这个分裂的分支存在，每个在推送之前的时间，再次执行git subtree split操作，这将构建您最后分割的点的子树的历史记录，它将更快。否则，如果不像你那样进行这种拆分，git subreee必须从你添加的点开始构建子树的历史，只要子树提交成长，建筑的时间就会越来越长。
如果您在添加时未使用--squash，则可以在分割时考虑使用--rejoin，这样会更快。
所以，步骤应该如下。
将lib添加到主项目中
git subtree add -P sub / libdir --squash lib_remote_url master
从lib获取更新
git subtree pull -P sub / libdir --squash lib_remote_url master
将子树更改拆分为单独的分支
git subtree split -P sub / libdir -b lib_remote_branch
将更改推送到lib_remote
git push lib_remote_url lib_remote_branch：master
保持lib_remote_branch存在并在下次推送时重做步骤3和步骤4.
答案 1 :(得分：1)
主要问题是自从你第一次添加以来对不同前缀的新提交。我对此问题的解决方案是执行“清理”操作，您可以过滤所有不在其他存储库中的更改，然后在此新分支上执行git子树添加。
这是一种相当蛮力的方式，但它与在主存储库的新副本上执行“git子树添加”基本相同。这是唯一对我有用的东西......