我正在使用git-subtree从我的项目中提取目录。
git subtree split --prefix=src/SubProject --branch=SubProject origin/master
鉴于这是我想要开始项目的方式（特别是没有--rejoin），如何在连续运行时仅将origin/master的更改拆分为SubProject？ / p>
对于较小的项目，这一直很好。我可以用大约5秒的时间来分割项目。但是在较大的存储库中，这可能需要相当长的时间。我发现每次拆分需要5分钟。我想要合作的一些项目在一个存储库中有超过45个子项目。
我尝试了许多我认为可行的东西，但每种东西都以这种或那种方式失败了。我的要求是：
origin/master（所以大部分--rejoin都是不可能的）--ff-only获取新的更改时请考虑origin/master）SubProject存储库必须具有稳定的提交ID。这意味着在对SubProject进行一次或多次增量更新后，如果我在此帖子的顶部重新运行原始命令，它在历史记录中应该具有相同的提交ID。我不怕复杂的解决方案，但需要自动化。因历史变迁而失败是好的;在那时，脚本可以回退以从头开始构建整个事物。在这种情况下，用户知道他们做了什么，所以他们可以从头开始经历一个很长的重建过程。 ：）
我尝试使用--rejoin并保留origin/master的额外副本，以便成为--rejoin添加的已更改历史记录的容器。我遇到的问题是，如果没有干预，我无法git rebase origin/master或git merge --ff-only origin/master。我需要能够以自动方式执行此操作，因此这是不可接受的。
我能够按照git merge origin/master的要求使用它，但它导致了合并提交。由于这个合并提交不会上游，我认为，未来的历史将无法预测，因此原始环境中的新git subtree split将无法再现相同的历史记录。 我可能错了。如果是这样，请向我解释这是如何安全的。 ：）
我尝试使用提交范围，我能够在SubProject中创建一个新的子树分割，它只包含从某个时间点到HEAD的提交列表。这可能会有效，除非它看起来好像生成了一组新的提交ID，所以我认为这不是一个选项。
答案 0 :(得分：3)
为subtree split实施a patch以简化此操作。现在，您可以显式指定在没有其他父项时填充的父项：
$ git init
$ for i in {1..100}; do
echo $i >q
git add q
git commit -m $i
mkdir -p qqq
echo $i > qqq/w
git add qqq/w
git commit -m "qqq/$i"
done
$ # let's do full split
$ /home/vi/src/git/git/contrib/subtree/git-subtree.sh split \
--prefix=qqq --branch qqq HEAD
...7/200 (6)...58/200 (57)...142/200 (141)...176/200 (175)...
Created branch 'qqq'
f5120d3e676e2966802c8829b13a34c8d0c2dac4
$ # now let's do partial split
$ /home/vi/src/git/git/contrib/subtree/git-subtree.sh split \
--prefix=qqq --branch qqq2 HEAD~100
...20/100 (19)...
Created branch 'qqq2'
3632fb9fc5c7a7f0b4bf8c6743e2cd372a6d8e52
$ # Now let's "continue the work" on qqq2
$ /home/vi/src/git/git/contrib/subtree/git-subtree.sh split \
--prefix=qqq --branch qqq2 \
--graft-parent=3632fb9fc5c7a7f0b4bf8c6743e2cd372a6d8e52 \
HEAD~100..HEAD
Grafting 3632fb9fc5c7a7f0b4bf8c6743e2cd372a6d8e52\n
...10/100 (9)...
Updated branch 'qqq2'
f5120d3e676e2966802c8829b13a34c8d0c2dac4