【发布时间】：2010-12-08 11:36:40
【问题描述】：
在我的项目中，我需要使用存储在多个 Git 存储库中的第三方代码。我的项目也存储在（单独的）Git 存储库中。有几个人和我一起做主项目，我是维护者。
在早期的项目中，我曾经手动将依赖项复制到 Git 工作树，添加一个小文件来指定我使用的版本。
现在这很不舒服，因为我需要每天更新一个依赖项，并且经常自己为其贡献代码，大部分时间都伴随着对主项目的更改。
我决定尝试使用 Git 子模块来进行管理。我越尝试它们，我就越沮丧。甚至手动复制似乎更好。
以下是我的一些担忧：
- 我们不再能够通过单个命令获得一致的存储库状态（
git checkout现在需要git submodule update --init）。 - 我们无法正确使用某些 Git 工具（最值得注意的是
git archive）。 - 我们无法看到主项目中子模块的状态变化/差异。
- 正如我刚刚发现的那样，
git submodule不适用于--git-dir和--work-tree选项，并且需要将当前目录物理更改为“工作树的顶层”。
似乎为了简化我们的子模块工作流程（即一个操作 == 一个命令），我们必须围绕 Git 编写一个相当厚的包装器。这很可悲。
请注意，离开 Git 或将子项目开发完全合并到主项目中不是一种选择。
也许我以错误的方式使用git submodules？有没有关于工作流程的好教程？
即使您不知道正确的答案，也请说出来，但请分享我的担忧。 :-)
【问题讨论】：
-
我最喜欢的另一个子模块陷阱之一是，如果你删除一个子模块，并在同一位置用一个新的子模块替换它，它会破坏其他人的存储库。 （例如，有人在 github 上 fork 一个库，而您将子模块切换为指向 fork。）解决方法是删除子模块，让每个人都拉取并更新，然后替换子模块并让所有人再次拉取并更新。
-
我以为有人偷了这篇文章并在没有参考的情况下将其发布在 habr 上，但后来我看了看名字... :-D 不过，我想参考 SO 会很好。
-
有一个。仔细查看文本中的链接。
-
只是想为
subtree选项贡献一个aditional link，来自Git 官方文档。
标签： git workflow git-submodules