Question

我有一个回购的子文件夹，我试图将其拆分为一个子树。首先，我按照此过程（https://stackoverflow.com/a/43985326/136785）创建一个分支，该分支仅包含与子文件夹相关的提交（包括重命名）。我确认分支的提交日志看起来像预期的那样。

接下来，我为该子项目创建一个新的仓库：

git init --bare \\nas\git\FPF.git
git push ssh://myserver.com/~/FPF.git branch-fpf:master

然后我从父仓库中删除该子文件夹，并将其重新添加为子树：

git rm -r htdocs/wp-content/plugins/fpf
git add -A
git commit -am "Removing folder to re-add as subtree"
git remote add fpf ssh://myserver.com/~/FPF.git
git subtree add --prefix=htdocs/wp-content/plugins/fpf fpf master --squash

现在，作为快速检查，我将获取远程子树存储库的副本（当然，在另一个文件夹中）：

git clone ssh://myserver.com/~/FPF.git

并且：

git subtree push --prefix=htdocs/wp-content/plugins/fpf fpf master

由于我尚未在添加子树和推送之间进行任何更改，我希望没有新内容可推送。但是事实证明，如果我再次克隆FPF.git，我发现它现在有大量的额外提交-FPF增长了很多倍，并且提交日志现在反映了许多仅适用于外部文件的提交子树。

为什么 git subtree push 会推送不适用于子树的提交？

编辑1：额外的提交是指从主（父）存储库中的所有提交（在第一次FPF提交之前开始并返回到时间的开始）。换句话说：如果在执行git子树推送之前和之后比较FPF子树仓库的日志，它们是相同的，直到到达“预推送”克隆日志的底部为止。从那里，“后推”克隆的日志一直持续到父项目的第一次提交。 Git子树推送有效地附加了父级的全部先前历史。

编辑2：我决定放弃git-subtree。我发现https://github.com/ingydotnet/git-subrepo不仅可以正常工作，而且可以解决许多子树的缺点（最值得注意的是非常缓慢的推动）。万一其他人想出答案或正在为之苦恼，请把这个问题留在这里，但为简化起见，这里有一个完整的从头到尾的命令集来展示这个问题。与上面的区别：这并非始于将多个过滤器分支嫁接在一起的分支；它只是完成单个子树拆分的最简单情况：

cd MainProjectRepo
git subtree split --prefix=htdocs/wp-content/plugins/fpf --branch=branch-new
git init --bare \\nas\git\FPF.git
git remote add fpf ssh://myserver.com/~/FPF.git
git push fpf branch-new:master
git rm -r htdocs/wp-content/plugins/fpf
git add -A
git commit -am "Removing folder to re-add as subtree"
git subtree add --prefix=htdocs/wp-content/plugins/fpf fpf master --squash

git clone ssh://myserver.com/~/FPF.git /tmp/fpf1
git subtree push --prefix=htdocs/wp-content/plugins/fpf fpf master
git clone ssh://myserver.com/~/FPF.git /tmp/fpf2

如上所述，fpf2最终包含了来自源存储库的所有提交历史记录。

Answer 1

对于可能遇到此问题的其他人：

我的结论是，经过许多小时的努力（阅读，讨论，以不同方式重试等），git-subtree不能正常工作。相反，我发现了一个更好的选择：git-subrepo。它不仅可以正常工作，而且还解决了子树的其他缺点-最明显的是非常缓慢的按下。

因此，我对如何解决此问题的“答案”是：放弃git-subtree并改用git-subrepo：）

Git子树推送似乎可以推送不适用于子树的提交？

1 个答案: