在工作中，我们正在开发十几个Java OSGi包，每个包都有自己的git存储库。从长远来看，所有捆绑包都是相互独立的，这证明了各个存储库的合理性 - 尽管现在我们仍然经常同时修改其中的几个。
当我们进行产品发布（包含所有捆绑包）时，会在每个捆绑包中创建一个新分支，这有点痛苦。因此我们考虑使用git-submodule来缓解疼痛（类似于git submodule foreach <cmd>）。
因此，我们所需的设置将是一个主项目Product，以及每个包的子模块：
Project/
BundleA/
BundleB/
BundleC/
现在，我花了几个小时阅读所有关于子模块的内容，我明白如果我修改BundleA中的内容，我必须提交BundleA，推送，然后提交子模块在Project中更改并再次推送。
这听起来好像不是git-submodule首先被设计为使用的方式。这样使用它是违反最佳做法的吗？或者听起来像是首选替代方案的情况？
欢迎任何其他建议。
答案 0 :(得分：6)
你不需要跟踪子项目在超级项目中的作用（紧密绑定），然后我建议你远离git-submodules。
gitslave（http://gitslave.sf.net）本质上是每个子项目的一个大型foreach，在超级项目中列出子项目的配置文件。有很多花铃和口哨使它更方便，但如果你的目标是在超级项目（可选）和所有子项目上运行相同的命令，gitslave就像你要找到的一样方便。
例如，在gitslave中创建一个新分支是：
gits checkout -b newbr
然后您的超级项目和所有子项目将创建新分支并更改为它。通常，如果要在超级项目的所有成员上运行gits命令，只需将“git”命令更改为“gits”。
答案 1 :(得分：2)
现在，我花了几个小时阅读所有关于子模块的内容，我明白如果我在BundleA中修改内容，我必须在BundleA中提交，推送，然后在Project中提交子模块更改并再次推送。
这听起来好像不是git-submodule首先被设计为使用的方式。这样使用它是违反最佳做法的吗？
我认为这正是应该如何使用子模块的，我担心。虽然假设通常你只是在主项目中提交一个新版本的情况相对较少，因为你强烈断言这个版本的子模块可以与主项目的那个版本一起正常工作。子模块系统的当前设计在其可以做的事情上受到相当的限制，因为主项目知道的关于子模块的唯一事情是：
.gitmodules中并在子模块初始化的config中设置...当你在子模块中工作时，就像在一个独立的存储库中工作一样，是否存在超级项目。
在你提到的简化这个过程的方法中，值得澄清的是，repo实际上不使用子模块 - 它是一个替代系统。这与git-slave类似，许多Stack Overflow用户似乎都建议这样做。
就个人而言，我从事一个项目，其主存储库有24个子模块，我们只用一个有用的脚本就可以了，它简化了提交新版本子模块的过程，并确保它被正确推送。
您可能希望查看的另一个（非子模块）替代方法是git-subtree，不要与子树合并策略混淆。