Git 如何减少不断增加的推送子树的时间？

我习惯于将几个子项目“链接”到主项目中（我来自“svn:externals”）。我已经使用它好几个星期了，但是每次提交时，将更改推送到远程子树的时间都会增加

$ git subtree push -P platform/rtos rtos master

git push using:  rtos master

1/    215 (0)2/    215 (1)3/    215 (2)4/    215 (3)5/    215 (4)6/    215 (5)7/    215 (6)8/    215 (7)9/    215 (8)10/    215 (9)11/    215 (9)12/    215 (10)13/    215 (11)14/    
...
20 more lines
...
(204)209/    215 (205)210/    215 (206)211/    215 (207)212/    215 (208)213/    215 (209)214/    215 (210)215/    215 (211)To https://github.com/rtos/rtos.git
   64546f..9454ce  9a9d34c5656655656565676768887899898767667348590 -> master

---

有没有办法“清理”子树，从而减少推动更改的时间？

没有，不幸的是没有。当您运行git子树推送时，它将为此子树重新创建所有提交。它必须这样做，因为它们的SHA依赖于以前的提交，并且需要那些SHA能够将新的提交链接到旧的提交。它可以缓存，但不能

我猜这就是使用子树和子模块所付出的代价。子树在您的存储库中是非常无状态的，这一方面很好，但另一方面会导致这种长时间的计算。子模块存储它们的所有信息，这需要您对其进行管理，但也使类似的内容更快。

尝试使用

--rejoin

标志，以便在拆分后子树正确合并回主存储库。这样一来，每次拆分都不需要经历所有历史

git subtree split --rejoin --prefix=<prefix> <commit...>

git子树拆分--重新连接--前缀=

从：

拆分后，合并新创建的合成 将历史记录返回到主项目中。这样，未来 拆分只能搜索已删除的历史部分 自最近一次--重新加入以来已添加

---

请注意，如果您决定切换到，现在可以（2013-03-08）跟踪子模块repo的最新提交

看

“git子模块”开始学习与远程分支的tip集成的新模式（而不是与超级项目的gitlink中记录的提交集成）

这有助于更快地推送，同时受益于子模块在子树上拥有的附加信息（即子模块特定提交的轻量级记录）

您可以使用以下命令将该子模块更新为给定分支的最新版本：

git submodule update --remote

此选项仅对

update

命令有效。
使用子模块远程跟踪分支的状态，而不是使用超级项目记录的SHA-1更新子模块

---

也许这会有帮助：我想你可以告诉

git subtree split

只返回n次提交

git subtree split --prefix XXX HEAD~n..

或者指定要开始的提交，例如

git subtree split --prefix XXX 0a8f4f0^..

---

这有助于减少时间，尽管这很不方便。

@LopSae的答案是可行的，但如果你使用挤压合并/拉取，它会让你的回购协议有很多提交

以下是避免这种情况的方法

git subtree split --rejoin --prefix=<subtree/path> --ignore-joins

git子树拆分--重新连接--前缀=--忽略连接

当你这样做的时候，你想把你拔出的树枝向后推。否则无法创建拉取请求

至少有两个选项可以处理此问题

重基

在远程项目上创建一个新分支，将其拉入并推回该分支

---

令人惊讶的是，

git子树

不能（不？）缓存这些信息，这样在第一次推送

git子树之后，一切都变得相对快速。@davidg它当然可以。尤其是在Windows上，速度慢得可笑。在我的例子中，当您达到600断言计数时，每次推送都需要一分钟以上的时间，使得git在这一点上毫无用处。子模块并不适用于所有人，问题是关于子树的。@ferraith如果您切换到子模块就可以了，但是使用社区的子树需要答案！你能选择另一个答案吗？@JorgeOrpinel你似乎想要一个更好的答案，就像我一样。。。如果你能发布一个好的答案，即使只是总结其他答案/文档，并解释细节，我相信你会得到一些选票：）对不起，安东尼，我现在已经放弃了Git子树。很久以前！不再熟悉了，哈哈。我的建议：不要使用它们。不错的选择，但这个问题是关于子树的。如果能找到答案就好了。用哪一个？我尝试过使用该子树的顶端，虽然它进行了拆分/重新连接（甚至不确定这意味着什么），但我的下一次子树推送也同样长：（为什么会这样做（你能解释一下使用拆分/重新连接时发生了什么吗）？我需要多久运行一次（一次？每一个未指定的事件一次？每次推送之前？）问题是关于
git子树推送
而不是
split
，我认为
rejoin
选项不适用。@AnthonyMastrean啊……git子树推送首先进行拆分。请检查原始文档。如果您真的尝试过，您可以看到它是如何工作的。我查看了源代码，是的，有一个
子树plit
在那里。但是我仍然没有遵循你的答案的机制…如果我们手动设置拆分/重新连接…这将使后续推送工作更好？它会创建一个拆分点，并从那里开始计算。你尝试过吗？
git subtree split
只将一个提交作为参数。