我觉得使用 Git 子模块对我的开发工作流程来说有点麻烦。我听说过 Git 子树和 Gitslave。
【问题讨论】：
标签： git-submodules git-subtree git-repo git-subrepo git-slave
哪种方法最适合您取决于您的需求、愿望和工作流程。它们在某种意义上是半同构的，只是其中一些比其他特定任务更容易使用。
gitslave 在您控制和开发子项目的时间与超级项目的时间差不多时很有用，此外，当您通常希望同时标记、分支、推送、拉取等所有存储库时。 gitslave 从未在我所知道的 Windows 上进行过测试。它需要 perl。
git-submodule 在您不控制子项目或更具体地希望将子项目修复为特定版本时更好，即使子项目发生更改。 git-submodule 是 git 的标准部分，因此可以在 windows 上运行。
git-subtree 为 git 的内置子树合并策略提供了一个前端。如果您更喜欢拥有单一存储库“统一”的 git 历史记录，那就更好了。与子树合并策略不同，将不同（目录）树的更改导出回原始项目更容易，但它不像 gitslave 甚至 git-submodule 那样自动。
repo 理论上与 gitslave 类似，但对于我发现的非 android 操作的记录并没有那么好。它相当专用于 Google Android 开发模型，仅原生支持少数 git 命令（尽管您可以运行任意命令），并且有限的原生支持不支持，例如，用于推送和签出的集中存储库分支似乎相当困难。
kitnet 的mr 是您在使用多个版本控制系统时想要使用的工具，但由于其最低公分母方法，主要限于仅 git 的超级项目。有很多方法可以运行任意命令，但它们的集成度不高。
【讨论】：
mr run git config ... 之类的东西，或者可能（甚至更糟）配置文件方法将特定命令别名为名称。当然，如果您知道某些 mr 功能在阅读手册页时并没有立即显现出来，我很想知道。
git/contrib 中可用。使用 Git 源代码树中的sudo make install install-doc prefix=/usr libexecdir=/usr/lib/git-core 在 Ubuntu 中安装（不与打包的 Git 一起使用）。
我目前使用子模块进行开发，而不仅仅是关联 3rd 方库。有一些方法可以让子模块的生活更轻松，尤其是当它们是合并或变基冲突的根源时。查看 ls-tree 以获取与子模块中的冲突有关的 2 个提交。这可能是子模块中人们最难处理的部分。目前，脚本将使这更容易使用。未来版本的 Git 应该有更好的原生支持来处理它们。
希望这会有所帮助。
【讨论】：
对于某些用例，我喜欢以下两种简单方法：
嵌套存储库。如果您的软件项目具有插件机制，并且每个插件都位于其自己的子目录中，那么 git-ignore 这些插件目录和在您的本地文件系统，使它们中的每一个都成为自己的 git 存储库。这样，您的所有文件都会形成一个目录树，但在不同的 git 存储库中进行管理。它不会混淆 git。
每包存储库。对于使用某种源代码包管理系统（gem / bundler、npm、pear 等）的软件项目，将您重用的代码到单独的 git 存储库中，然后从中制作源包，然后使用包管理工具将它们安装到父项目中。您的父项目的 git 存储库将仅包含对所需包及其版本的引用，而这些包的实际代码将被 git 忽略，就像所有其他包和外部库一样。与上面提出的嵌套存储库相比，这是一种更精细的方法，因为它允许指定要安装的软件包版本。
【讨论】：
在我们有多种语言的依赖项的项目中使用 Git 子模块时，我们遇到了类似的问题。为了处理它们，我们构建并开源了一个名为 MDLR（“Modular”）的工具，它为您提供声明式版本控制的 Git 依赖项，具有与 Git 子模块类似的功能，但没有烦人的工作流程。您可以使用GitHub repo 上的说明/下载来安装它并管理您的依赖项
【讨论】：