使用进行提交的Git子模块时，有哪些选择？

如果您不需要跟踪子项目在超级项目中的工作（紧密绑定），那么我建议您远离git-submodules。 gitslave（http://gitslave.sf.net）本质上是一个很大的foreach，每个子项目都有一个超级文件，该文件在超级项目中列出了子项目。有很多风吹草动，这使它更加方便，但是如果您的目标是在超级项目（可选）和所有子项目上运行相同的命令，则gitslave会像您将要找到的一样方便。 因此，例如，在gitslave中创建一个新分支是： gits checkout -b newbr 然后，您的超级项目和所有子项目将创建新分支并更改为该分支。通常，如果要在超级项目的所有成员上运行gits命令，只需将\“ git \”命令更改为\“ gits \”。     

  现在，我已经花了几个小时阅读有关子模块的所有信息，并且我了解到，如果我在BundleA中进行修改，则必须在BundleA中进行提交，然后再推送，然后在Project中提交子模块更改，然后再次进行推送。      显然，这听起来似乎不是最初设计git-submodule的方式。像这样使用它是否违反了最佳实践？ 恐怕我认为这正是应该使用子模块的方式。尽管可能通常是假设您只是相对很少地在主项目中提交新版本，因为您强烈断言子模块的该版本可以与主项目的该版本正常工作。子模块系统的当前设计在功能上受到很大限制，因为主项目对子模块的唯一了解是： 子模块应该位于什么提交位置，存储在树中，而不是Blob或树的哈希 （应该）包含提交的存储库的默认URL，存储在“ 6”中，并在子模块初始化时在config中设置 ...当您在子模块中工作时，就像在独立存储库中工作一样，无论那里是否有超级项目。 在简化您提到的此过程的方法中，值得澄清的是，回购实际上并不使用子模块-它是替代系统。 git-slave的情况与此类似，许多Stack Overflow用户似乎都建议这样做。 就我个人而言，我正在一个项目中工作，该项目的主存储库包含24个子模块，我们仅用了一个有用的脚本就可以了，该脚本简化了提交子模块的新版本并确保正确推送该子模块的过程。 您可能要看的另一种（非子模块）替代方案是git-subtree，不要与子树合并策略混淆。