【问题标题】:Split Up Folders in a git repository into separate branches将 git 存储库中的文件夹拆分为单独的分支
【发布时间】:2012-03-03 00:25:33
【问题描述】:

我终于将我们的 CVS 存储库迁移到了 git。不幸的是,我们没有在 CVS 中使用分支,而是将不同的版本/分支分隔到不同的子目录中。

I.E.我们有以下目录结构:

/root
    /lib
    /tools
    /src
        /v1.0
        /v2.0
        /v3.5

有没有办法将 src 子目录中的 3 个版本分成单独的分支,而不是为每个版本保留目录?

我在 Stack Overflow Question 4877053 上发现了同样的问题,其中建议使用 git-subtree,但即使在阅读了 git-subtree 的手册之后,我也不明白如何使用它来解决我的问题问题。

谁能给我更详细的解释,甚至是另一种解决方案?

我对git很陌生,也许这就是我不理解子树手册的原因;-)

非常感谢您的所有回答!

【问题讨论】:

  • 你有与不同版本目录相关的提交历史吗?当您将 CVS 存储库迁移到 git 时,您现在是否有想要保留的历史记录?我很确定您可以使用git filter-branchgit merge 的组合来拆分这些目录,但是如果不知道您想要保留什么或您希望最终存储库是什么样子,就很难确定。跨度>

标签: git git-subtree


【解决方案1】:

这取决于您之后想要在存储库中留下什么。

如果你想要三个分支,v1.0v2.0v3.5,都具有这样的结构:

/root
    /lib
    /tools
    /src

那么是的,我很确定你可以做到这一点。就分支结构而言,您最终会得到类似的结果:

-- A -- B -- Current 
              | 
              |--- v1.0
              |--- v2.0
              |--- v3.5

ABCurrent 是您在迁移到 git 后提交的提交,其中 v1.0v2.0v3.5 本质上是“死胡同”分支。如果你想得到一个更像这样的分支结构,你可以做一些花哨的事情:

-- v1.0 --- v2.0 --- v3.5 -- A -- B -- Current

也就是说,将v1.0v2.0v3.5 分离到它们自己的分支中,然后将v1.0 重新定位到v2.0v2.0v3.5v3.5 到第一个提交上在当前版本中。

但我不确定你到底想做什么。


有没有办法将 src 子目录中的 3 个版本分成单独的分支,而不是为每个版本保留目录?

是的,我很确定你可以做到这一点。我的方法有点……令人费解,我承认,但这里有。 ,小心并阅读手册页 - 以下命令可能不会搞砸一切,但使用风险自负。

  1. git checkout -b v1.0 - 进入一个新分支。
  2. 删除除v1.0 之外的所有内容。有几种方法可以做到这一点。这个问题有一些方法可以删除除 ;我不能让他们为我工作,它可能对你更好。

    `git filter-branch --index-filter "git rm -r -f --cached --ignore-unmatch src/v2.0" --prune-empty -f`
    

    这将从分支中删除src/v2.0 和所有相关的历史记录-f 对于这个过滤器不是必需的;但是git-filter-branch 做了某种备份(阅读手册页?),它可能会吐出错误。它肯定会在您第二次尝试git filter-branch 时出现。

    重复此操作以删除src/v3.5

    这将为您留下src/v1.0。您可能希望将源从src/v1.0 转移到src;您可以运行git filter-branch --subdirectory-filter(阅读手册页)来获取目录结构/v1.0-files(只包含子目录v1.0 中的文件;已将内容从v1.0 移动到root),然后查看在man git-filter-branch 页面中的示例(特别是底部示例)中将文件转移到子目录中。这可能有点矫枉过正,然后您需要将 that 合并到一个包含 git filter-branch --subdirectory 剔除的所有其他内容的分支中;一个简单的mv v1.0/* . 可能会起作用,但是您的历史记录中会有另一个提交。我不知道你喜欢什么。

    所以现在你在它自己的分支中有v1.0。耶!

  3. 重复 v2.0v3.5

恐怕除了给你……“奇怪”的历史之外,我什么也做不了。大概v2.0 本质上具有v1.0 + 改进;我在上面列出的结构(三个“死胡同”分支)显示 v2.0v3.5 不是在以前的版本上构建的。我不完全确定你有什么样的历史,如果这是一个问题等等。

因为您在自己的小分支中有v1.0v2.0v3.5,如果您想要更好看的历史记录,您可以git merge 他们或git rebase 等等。

希望这能让你思考一下;就像我说的,请阅读手册页。 :)

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-06-20
    • 2011-01-05
    • 2014-01-12
    • 1970-01-01
    • 2016-01-23
    • 2017-03-13
    • 2013-03-03
    • 2017-08-17
    相关资源
    最近更新 更多