值得一提的是，下面是如何在Windows机器上使用GitHub。假设您在C:\dir1中有一个克隆的repo。目录结构如下：C:\dir1\dir2\dir3。dir3目录是我希望成为一个新的独立存储库的目录。

github：

创建新存储库：MyTeam/mynewrepo

猛击提示：

$cd c:/Dir1$gitfilter分支--修剪空--子目录筛选器dir2/dir3 HEAD返回：Ref“refs/heads/master”已重写（fyi:dir2/dir3区分大小写。）$git远程添加some_namegit@github.com：我的团队/mynewrepo.gitgit远程添加原点等不起作用，返回“远程原点已存在”$git push--进度some_name master

原始问题希望XYZ/ABC/（*文件）变为ABC/ABC/“*文件”。在为我自己的代码实现了公认的答案后，我注意到它实际上将XYZ/ABC/（*文件）更改为ABC/（*）文件。过滤器分支手册页甚至说，

结果将包含该目录（并且仅包含该目录）作为其项目根目录。"

换句话说，它将顶级文件夹“提升”一个级别。这是一个重要的区别，因为例如，在我的历史中，我重命名了一个顶级文件夹。通过将文件夹“提升”一级，git在我进行重命名的提交时失去了连续性。

我对这个问题的回答是制作存储库的两个副本，然后手动删除每个副本中要保留的文件夹。手册页支持我：

[…]如果一次简单的提交就足以解决您的问题，请避免使用[此命令]

这里是对CoolAJ86的“简单方法”的一个小修改™回答，以便将多个子文件夹（假设sub1和sub2）拆分为一个新的git存储库。

简单的方法™ （多个子文件夹）

准备旧回购推送<大回购>gitfilter分支--树过滤器“mkdir<文件夹名称>；mv<sub1><sub2><文件夹名称>/”HEADgit子树拆分-P<文件夹名称>-b<新分支名称>邻苯二胺注意：＜文件夹名称＞不能包含前导或尾随字符。例如，名为subject的文件夹必须作为子项目传递，而不是/子项目/windows用户注意：当文件夹深度>1时，＜文件夹名称＞必须具有*nix样式的文件夹分隔符（/）。例如，名为path1\path2\subject的文件夹必须作为path1/path2/subject传递。此外，不要使用mvcommand，而是移动。最后一点：与基本答案的最大区别是脚本“gitfilter分支…”的第二行创建新回购mkdir<新回购>推送<新回购>初始化git pull＜/path/to/big repo＞＜新分支的名称＞将新回购链接到Github或任何地方git远程添加原点<git@github.com：我的用户/new repo.git>git推送原点-u主清理（如果需要）popd#退出<新回购>推送<大回购>gitrm-rf＜文件夹名称＞注意：这会将所有历史引用保留在存储库中。如果您确实担心提交了密码或需要减小.git文件夹的文件大小，请参阅原始答案中的附录。

我找到了非常直接的解决方案，这个想法是复制存储库，然后删除不必要的部分。这是它的工作原理：

1） 克隆要拆分的存储库

git clone git@git.thehost.io:testrepo/test.git

2） 移动到git文件夹

cd test/

2） 删除不必要的文件夹并提交

rm -r ABC/
git add .
enter code here
git commit -m 'Remove ABC'

3） 使用BFG从历史记录中删除不必要的文件夹

cd ..
java -jar bfg.jar --delete-folders "{ABC}" test
cd test/
git reflog expire --expire=now --all && git gc --prune=now --aggressive

对于多个文件夹，可以使用逗号java-jar bfg.jar--删除文件夹“｛ABC1，ABC2｝”metric.git

4） 检查历史记录是否不包含您刚刚删除的文件/文件夹

git log --diff-filter=D --summary | grep delete

5） 现在您有了没有ABC的干净存储库，所以把它推到新的原点

remote add origin git@github.com:username/new_repo
git push -u origin master

就是这样。您可以重复这些步骤来获取另一个存储库，

只需在步骤3中删除XY1、XY2并重命名XYZ->ABC

我确信git子树很好，很好，但我想移动的git托管代码子目录都在eclipse中。所以，如果你使用egit，这非常容易。将要移动的项目与团队->断开连接，然后团队->将其共享到新位置。默认情况下，它将尝试使用旧的回购位置，但您可以取消选中使用现有选择并选择新位置来移动它。大家都来了。

如上所述，我必须使用相反的解决方案（删除所有提交而不触及我的dir/subdr/targetdir），这似乎可以很好地去除大约95%的提交（根据需要）。然而，还有两个小问题。

首先，过滤器分支完成了一项出色的工作，删除了引入或修改代码的提交，但显然，合并提交在Gitiverse的站点之下。

截图：合并疯狂！

这是一个我可能可以忍受的美容问题（他说……慢慢后退，眼睛转向）。

第二，剩下的几个提交几乎都是重复的！我似乎获得了第二个多余的时间线，它几乎涵盖了整个项目的历史。有趣的是（你可以从下面的图片中看到），我的三个本地分支并不都在同一个时间线上（这就是为什么它存在，而不仅仅是垃圾收集）。

尖叫：双双，Git过滤器分支样式

我唯一能想到的是，其中一个被删除的提交可能是过滤器分支实际删除的单个合并提交，并且创建了并行时间线，因为每个现在未合并的链都有自己的提交副本。（耸耸肩，我的TARDiS在哪里？）我很确定我能解决这个问题，尽管我真的很想知道它是怎么发生的。

对于疯狂的mergefest-O-RAMA，我很可能会把它单独放在一边，因为它在我的承诺历史中根深蒂固，每当我走近时，它都会威胁我——它似乎并没有真正引起任何非外观问题，因为在Tower.app中它非常漂亮。