我有一个项目依赖于另外两个使用子树合并策略合并的子项目（described here和there）？
过了一段时间，我注意到其中一个子项目在当前项目中有自己的生命周期，所以我想将它与原始项目分离，但我不知道如何实现这一点。
基本上，我注意到子项目列在.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）中
答案 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”的历史交织的“子树”合并转移到使用submodule（tutorial）可以实现更多分离。在这种情况下，您将拥有LibraryB的单独存储库（fork），但它将位于ProjectA的工作区域内; ProjectA中的提交将有而不是将LibraryB树作为子树，指向要在LibraryB存储库中提交的指针。然后，如果您不想遵循LibraryB开发，那么仅仅不使用'git submodule update'就足够了（也许只是为了注释掉或删除指向LibraryB的规范版本的链接）。
这样做的好处是可以轻松地将您的改进发送到规范的LibraryB，以及您在ProjectA的工作区域内进行更改的优势。它的缺点是必须学习稍微不同的工作流程。
此外，还存在如何从“子树”合并到子模块的问题。你可以：
我希望这个版本可以解决你的问题。
免责声明： 我既未使用子树合并，也未使用子模块，也未使用git-filter-branch。