11

我一直在使用 git 子树扩展 ( https://github.com/apenwarr/git-subtree )。我使用“--squash”来清理主项目的日志，我的步骤是这样的：

  1. 将lib添加到主项目中

    git subtree add -P sub/libdir --squash lib_remote master

  2. 从 lib 获取更新

    git subtree pull -P sub/libdir --squash lib_remote master

  3. 将更改推送到 lib_remote

    git subtree push -P sub/libdir --squash lib_remote master

它对我来说效果很好（主要项目和库，有一个很有意义的历史）。问题是 git subtree push 的时间，越来越长。

我使用 git-subtree 的目的与 Screndib 几乎相同，他们问 git-subtree 没有保留历史记录，所以我无法推送子树更改，我该如何解决这个问题/以后避免这个问题？

我想，当使用 --squash 时，每次处理 push 时， git subtree 都需要搜索自“subtree add”以来的整个历史记录。

如何减少子树推送的时间？或者让它更有效地工作，而不是整个历史，只处理自上次 git subtree push（或 pull）以来的更改？

4

2 回答 2

5

我假设您的代码中的“lib_remote”是远程库 repo 的 url，而不是您当前 repo 中的分支？当前仓库中的远程仓库 url 和分支都在工作。

我看到你git subtree add用来将远程库添加为子树，然后你只是git subtree push用来推送更改。

最好git subtree split在 push 操作之前将子树更改拆分到您当前 repo 中的单独分支，然后将拆分的分支推送到远程 repo 并保持此拆分分支存在，每次推送之前，做一个git subtree split操作同样，这将从您上次拆分的点开始构建子树的历史记录，它会快得多。否则，如果没有像您那样进行拆分，git subtreee 必须从您添加的点开始构建子树的历史，只要子树提交增长，构建的时间就会越来越长。

如果不--squash加时使用，可以考虑--rejoin分时使用，这样会快很多。

所以，步骤应该如下。

  1. 将lib添加到主项目中

    git subtree add -P sub/libdir --squash lib_remote_url master

  2. 从 lib 获取更新

    git subtree pull -P sub/libdir --squash lib_remote_url master

  3. 将子树更改拆分为单独的分支

    git subtree split -P sub/libdir -b lib_remote_branch

  4. 将更改推送到 lib_remote

    git push lib_remote_url lib_remote_branch:master

保持 lib_remote_branch 存在，下次推送时重做第 3 步和第 4 步。

于 2012-03-09T12:52:49.080 回答
1

主要问题是自从您第一次添加以来，不同前缀上的新提交。我对这个问题的解决方案是执行“清理”操作，过滤所有不在其他存储库中的更改，然后在这个新分支上执行 git subtree add 。

这是一种相当蛮力的做法，但它基本上与在主存储库的新副本上执行“git subtree add”相同。那是唯一对我有用的东西......

于 2013-04-09T15:08:10.883 回答