6

在工作中，我们正在开发十几个 Java OSGi 包，每个包都有自己的 git 存储库。从长远来看，所有捆绑软件都将相互独立，这证明了单独的存储库是合理的——尽管现在我们仍然经常同时修改其中的几个。

当我们发布产品（包含所有捆绑包）时，会在每个捆绑包中创建一个新分支，这有点麻烦。因此，我们正在考虑使用 git-submodule 来减轻痛苦（类似于git submodule foreach <cmd>）。

因此，我们想要的设置将是一个主项目Product，以及每个包的子模块：

Project/
  BundleA/
  BundleB/
  BundleC/

现在，我花了几个小时阅读我能找到的关于子模块的所有内容，我明白如果我在 中修改内容BundleA，我必须在 中提交BundleA、推送，然后提交子模块更改Project并再次推送。

这显然听起来不是 git-submodule 最初被设计为使用的方式。像这样使用它是否违反最佳实践？还是听起来像是首选替代方案的情况？

  • 准系统 git-submodule 使用
  • 使用现有的“git wrapper”：
  • 编写我自己的简单 bash 脚本来批处理 OSGi 包

欢迎任何其他建议。

4

2 回答 2

6

如果您不需要跟踪子项目在超级项目中所做的事情（紧密绑定），那么我建议您远离 git-submodules。

gitslave（http://gitslave.sf.net）本质上是一个围绕每个子项目的大型 foreach，在超级项目中列出了子项目的配置文件。有很多花里胡哨的东西使它更方便，但是如果您的目标是在超级项目（可选）和所有子项目上运行相同的命令，那么 gitslave 与您将找到的一样方便。

因此，例如，在 gitslave 中创建一个新分支是：

gits 结帐 -b newbr

然后您的超级项目和所有子项目将创建新分支并更改为它。一般来说，如果要对超级项目的所有成员运行 gits 命令，只需将“git”命令更改为“gits”即可。

于 2011-05-24T13:18:16.533 回答
2

现在，我花了几个小时阅读我能找到的关于子模块的所有内容，我明白如果我在 BundleA 中修改内容，我必须在 BundleA 中提交，推送，然后在 Project 中提交子模块更改并再次推送。

这显然听起来不是 git-submodule 最初被设计为使用的方式。像这样使用它是否违反最佳实践？

我认为这正是子模块应该被使用的方式，恐怕。尽管通常假设您通常只在主项目中相对不频繁地提交一个新版本，因为您强烈断言该版本的子模块可以与该版本的主项目正常工作。子模块系统的当前设计在它可以做的事情上受到相当的限制，因为主项目对子模块的唯一了解是：

  • 子模块应该在什么提交，存储在树中，而不是 blob 或树的哈希
  • （应该）包含该提交的存储库的默认 URL，.gitmodules在子模块初始化时存储并设置在配置中

...当您在子模块中工作时，就像在独立存储库中工作一样，无论那里是否有超级项目。

在您提到的简化此过程的方法中，值得澄清的是 repo 实际上不使用子模块 - 它是一个替代系统。这与 git-slave 的情况类似，许多 Stack Overflow 用户似乎都推荐这种情况。

就个人而言，我在一个项目的主存储库有 24 个子模块，我们已经做得很好，只是一个有用的脚本，它简化了提交新版本的子模块并确保它被正确推送的过程。

您可能想要查看的另一个（非子模块）替代方案是git-subtree，不要与子树合并策略混淆。

于 2011-05-24T10:58:11.610 回答