我git-subtree
用来从我的项目中提取目录。
git subtree split --prefix=src/SubProject --branch=SubProject origin/master
鉴于这就是我希望开始项目的方式(特别是 no ),我如何才能在连续运行时--rejoin
仅将更改从origin/master
to拆分?SubProject
对于较小的项目,这一直运行良好。我可以忍受大约 5 秒的时间来拆分项目。但在较大的存储库上,这可能需要相当长的时间。我已经看到每次拆分最多需要五分钟。我想合作的一些项目在一个存储库中有超过 45 个子项目。
我尝试了很多我认为可能有效的方法,但每一种都以某种方式失败了。我的要求是:
- 不得以任何方式弄乱
origin/master
(所以大多数情况--rejoin
下是不可能的) - 它不能添加额外的合并提交(想想:
--ff-only
当从 获取新更改时origin/master
) - 存储库
SubProject
必须具有稳定的提交 ID。这意味着在对 进行一次或多次增量更新后SubProject
,如果我重新运行本文顶部的原始命令,它的历史记录中应该具有相同的提交 ID。 - 它必须是自动化的,不需要人工干预
我不害怕复杂的解决方案,但它需要自动化。因为历史改变而失败是好的;此时脚本可以退回以从头开始构建整个事物。在这种情况下,用户知道他们做了什么,所以他们可以从头开始经历一个非常漫长的重建过程。:)
--重新加入
我尝试使用--rejoin
并保留一个额外的origin/master
around副本,作为--rejoin
. 我在这里遇到的问题是我无法干预git rebase origin/master
或git merge --ff-only origin/master
不干预。我需要能够以自动化的方式做到这一点,所以这是不可接受的。
合并提交
我能够让它按我的意愿工作,git merge origin/master
但它导致了合并提交。由于此合并提交永远不会上游,因此我认为无法预测未来的历史,因此git subtree split
原始环境中的新鲜事物将无法重现相同的确切历史。我可能错了。如果是这样,请向我解释这将如何安全。:)
提交范围
我尝试使用提交范围,并且能够创建一个新的子树拆分,SubProject
其中仅包含从某个时间点到HEAD
. 这可能会起作用,除非它看起来好像生成了一组新的提交 ID,所以我认为这不是一个选项。