我觉得使用Git子模块对于我的开发工作流程来说有点麻烦。我听说过Git子树和Gitslave。
答案 0 :(得分：89)
哪种方式最适合您，取决于您的需求，愿望和工作流程。它们在某种意义上是半同构的，只有一些比其他方法更容易用于特定任务。
gitslave在您控制和开发子项目时非常有用，与超级项目同时进行控制和开发，此外，当您通常需要标记，分支，推送，拉取等所有存储库时同时。 gitslave从未在我知道的窗户上进行过测试。它需要perl。
git-submodule在您不控制子项目或更具体地希望在特定修订版本上修复子项目时更好，即使子项目发生更改也是如此。 git-submodule是git的标准部分，因此适用于Windows。
git-subtree为git的内置子树合并策略提供了前端。如果您希望拥有单一存储库“统一”git历史记录，那就更好了。与子树合并策略不同，将更改导出到不同的（目录）树更容易返回到原始项目，但它不像gitslave甚至git-submodule那样自动。
repo在理论上类似于gitslave，但对于我发现的非Android操作没有详细记录。它非常专注于Google Android开发模型，并且本身仅支持少量git命令（尽管您可以运行任意命令），并且有限的本机支持不支持，例如，集中式存储库可以推送和检出分支似乎相当困难。
kitenet的mr是您在使用多个版本控制系统时想要使用的内容，但由于其最小的公分母方法，因此仅限于仅限git的超级项目。有一些方法可以运行任意命令，但它们没有很好地集成。
答案 1 :(得分：1)
备用列表中的新增加项是Git X-Modules。这是为了避免here中所述的Git子模块的典型缺陷。主要区别在于所有同步都是在服务器端完成的，因此对于最终用户而言，他们只是克隆并推送到常规Git存储库。
答案 2 :(得分：0)
我目前使用子模块进行开发，而不仅仅是关联第三方库。有些方法可以让子模块更轻松，尤其是当它们是合并或rebase冲突的来源时。查看ls-tree以获取子模块中的冲突所涉及的2次提交。这可能是人们处理子模块中最困难的部分。目前，脚本编写将使这更容易使用。未来版本的Git应该有更好的原生支持来处理它们。
希望这有帮助。
答案 3 :(得分：0)
在具有多种语言依赖性的项目中使用Git子模块时，我们遇到了类似的问题。为了解决这些问题，我们构建并开源了一个名为MDLR（“模块化”）的工具，该工具为您提供了声明式版本控制的Git依赖项，具有与Git子模块类似的功能，但没有烦人的工作流程。您可以按照GitHub repo
上的说明/下载来安装和管理依赖项答案 4 :(得分：0)
对于某些用例，我喜欢以下两种简单的方法：
嵌套存储库。如果您的软件项目具有插件机制，并且每个插件都位于其自己的子目录中，则可以忽略这些插件目录，而在您的本地文件系统，以使它们每个都进入自己的git存储库。这样，所有文件都形成一个目录树，但是在不同的git存储库中进行管理。不会混淆git。
每个软件包的存储库。对于使用某种源代码软件包管理系统（gem / bundler，npm，pear或类似软件）的软件项目，放置将重用的代码放入单独的git存储库中，然后从它们中生成源软件包，然后使用软件包管理工具将它们安装到父项目中。您父项目的git存储库将仅包含对所需软件包及其版本的引用，而与所有其他软件包和外部库一样，这些软件包的实际代码也将被git忽略。与上面建议的嵌套存储库相比，这是一种更为复杂的方法，因为它可以指定要安装的软件包版本。