我正在使用git-subtree从项目中提取目录.
git subtree split --prefix=src/SubProject --branch=SubProject origin/master
鉴于这是我怎么想启动项目开始与(特别是不--rejoin)如何从分裂只有改变origin/master以SubProject在后续运行？
对于较小的项目,这一直很好.我可以用大约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,所以我认为这不是一个选项.
京公网安备 11010802040832号 | 京ICP备19059560号-6 