我一直在使用git子树扩展名(https://github.com/apenwarr/git-subtree)。
我使用“--squash”来清理主项目的日志，我的步骤是这样的:
git subtree add -P sub/libdir --squash lib_remote主
git subtree pull -P sub/libdir --squash lib_remote主
git subtree push -P sub/libdir --squash lib_remote主
它对我来说非常有效(主要项目和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时，每次处理一次push时，git子树都需要搜索自“子树添加”以来的整个历史记录。
如何减少子树推送的时间？还是使其更有效，而不是整个历史，仅自上次git子树push(或pull)以来的过程更改？
最佳答案
我假设您的代码中的“lib_remote”是远程库存储库的URL，而不是您当前存储库中的一个分支？远程仓库URL和当前仓库中的分支都可以使用。
我看到您正在使用git subtree add将远程库添加为子树，然后仅使用git subtree push进行更改。
最好执行git subtree split操作，以在推送操作之前将子树更改拆分到当前仓库中的单独分支中，然后将拆分后的分支推送到远程仓库中，并保持此拆分的分支存在，每次在推送之前进行一次再次进行git subtree split操作，这将以您上次拆分的点为基础构建子树的历史记录，它将更快。否则，如果没有像您一样进行此拆分，则git subtreee必须从添加的点开始构建subree的历史记录，只要该subtree提交不断增长，构建时间就会越来越长。
如果添加时不使用--squash，则可以考虑在拆分时使用--rejoin，这样会更快。
因此，该步骤应为以下步骤。
git subtree add -P sub/libdir --squash lib_remote_url主
git subtree pull -P sub/libdir --squash lib_remote_url主
git subtree split -P sub/libdir -b lib_remote_branch
git push lib_remote_url lib_remote_branch:master
保持lib_remote_branch存在，并在下次推送时重做步骤3和步骤4。