如何删除git子树合并?

时间:2009-02-20 19:11:15

标签: git

我有一个项目依赖于另外两个使用子树合并策略合并的子项目(described herethere)?

过了一段时间,我注意到其中一个子项目在当前项目中有自己的生命周期,所以我想将它与原始项目分离,但我不知道如何实现这一点。

基本上,我注意到子项目列在.git / config文件中,所以我想知道它是否足以从那里删除它。

根据Jakub的回答/问题,我会尝试在我的问题中添加更多详细信息。我在ProjectA上工作的项目取决于库LibraryB,它有自己的git存储库和自己的生命周期。 在设置ProjectA时,我使用了子树合并技术来添加LibraryB的依赖关系(这些步骤正好是VonC感谢添加的链接中描述的步骤)。 现在,ProjectA需要对LibraryB进行一些自定义更改,这些更改不够通用,无法推送回LibraryB存储库。所以,我想将ProjectA中的LibraryB与其主存储库分离(通过解耦,我意味着ProjectA中的LibraryB将无法从其主存储库更新,并且将仅在ProjectA内部跟踪其自己的历史记录)。

更多细节:在检查我的ProjectA存储库之后,我发现对LibraryB存储库的唯一引用存在于ProjectA / .git / config文件中:

[remote "gaelib"]
    url = ../libraries/gaelib
    fetch = +refs/heads/*:refs/remotes/gaelib/*

并且目录LibraryB中没有其他git相关信息包含在ProjectA(../ libraries / gaelib)中

4 个答案:

答案 0 :(得分:4)

听起来您想要“撤消”子树合并并将其提交回上游。 git subtree split命令应该这样做。

答案 1 :(得分:3)

我不明白。如果您使用子树合并方法将projectB包含在projectA存储库中,则不必进行任何解耦。您已经拥有了所需的一切:

  • 您可以从libraryB存储库中提取对libraryB的更新。我猜,这是件好事。

  • 您可以在projectA的存储库中提交对libraryB的更改。除非您决定将其推送/拉到另一个存储库,否则此更改将保留在此存储库的本地。它们只是projectA历史记录的一部分,不会自动传播到libraryB存储库。

这是子树合并方法的重点,而不是子模块方法。

答案 2 :(得分:2)

是的,从配置文件中删除指向libraryB的远程。这样可以防止任何使用您的repo的人无意中从遥控器更新您的本地代码。

你不需要做任何其他事情 - 你根本不再拉出或推送到LibraryB仓库。

答案 3 :(得分:0)

如果您想维护自己的LibraryB版本,可以选择以下几种方法:

  • 您可以使LibraryB成为项目的固有部分:只需删除或注释掉配置文件中的[remote "LibraryB"]部分,然后在项目中更改LibraryB。

    缺点是为LibraryB的规范(第三方)版本发送补丁会更加困难

  • 您可以继续使用“子树”合并,但不能使用规范版本的LibraryB,而是使用此库中您自己的克隆(fork)。您可以将remote.LibraryB.url更改为指向本地版本,并且您的本地版本将是原始LibraryB的克隆。请注意,您应该合并自己的分支,而不是规范LibraryB的远程跟踪分支。

    缺点是您必须维护单独的克隆,并且要记住您自己的更改(至少是那些通用的)必须在LibraryB的fork中进行,而不是直接在ProjectA中进行。

  • 您可能希望从将“ProjectA”和“LibraryB”的历史交织的“子树”合并转移到使用submoduletutorial)可以实现更多分离。在这种情况下,您将拥有LibraryB的单独存储库(fork),但它将位于ProjectA的工作区域内; ProjectA中的提交将有而不是将LibraryB树作为子树,指向要在LibraryB存储库中提交的指针。然后,如果您不想遵循LibraryB开发,那么仅仅不使用'git submodule update'就足够了(也许只是为了注释掉或删除指向LibraryB的规范版本的链接)。

    这样做的好处是可以轻松地将您的改进发送到规范的LibraryB,以及您在ProjectA的工作区域内进行更改的优势。它的缺点是必须学习稍微不同的工作流程。

    此外,还存在如何从“子树”合并到子模块的问题。你可以:

    • 通过在superproject工作存储库中的子项目子树中创建git存储库(即在适当的子目录中的“git init”+适当的“git submodule init”等),从子树合并移动到子模块。这意味着您将拥有“子树”到某个历史点,以及稍后的子模块。
    • 使用git filter-branch重写历史记录以通过子模块替换子树合并。这样做的缺点是重写历史记录(如果有人基于他/她对当前历史的研究工作,那就很大了),以及'干净启动'的优势。 或者你可以稍等一下“git submodule split”(thread on git mailing list)使它成为git ...
      不幸的是,Splitting a git repository博客帖子会返回“找不到主机”

我希望这个版本可以解决你的问题。

免责声明: 我既未使用子树合并,也未使用子模块,也未使用git-filter-branch。