使用 Git 子模块的正确方法是什么
我有 git 项目，它们共享一个公共库作为 git 子模块。 当我对项目进行任何更改时，我总是创建一个 git 分支来完成我的工作。在测试并给予另一组眼睛之后，我将分支合并回 master，它始终准备好部署。
有时我也需要对子模块库进行更改。最佳实践是否是首先对主项目进行分支，然后进入子模块并对其进行分支？我意识到我需要在其他使用的项目中测试修改后的子模块分支。有其他方法可以做到这一点吗？
I have git projects that share a common library as a git submodule.
When I make any changes to a project, I always create a git branch to do my work in. After testing and given another set of eyes, I merge the branch back into master which is always ready to deploy.
Sometimes I need to make changes to the submodule library as well. Would the best practice be to first branch the main project and then go into the submodule and branch it also? I realize then I would need to test the modified submodule branch in the other projects where used. Is there a different way to be doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
分支或不分支子模块，这是一个问题，但这完全取决于你。
如果您的子模块是一个库，并且其他项目正在使用它，那么它必须保持向后兼容。您可以修复其中的内容，但不要触及它的 API。但库修复实际上属于库的主分支。因此，我认为当您分支主项目时没有理由自动分支子模块。
从技术上讲，重要的是：如果您同时修改并提交子模块和主项目，请先推送子模块，然后再推送主项目。
不存在递归推送这样的事情。
To branch or not to branch the submodule, that is the question, but it's totally up to you.
If your submodule is a library, and other projects are using it, then it must remain backward compatible. You may fix things in it, but don't touch its API. But the lib fixes actually belong to the master branch of the lib. So I don't see a reason to branch the submodule automatically when you branch the main project.
Technically, the important thing is: if you modify and commit both the submodule and the main project, push the submodule first and then the main project.
There is no such thing as a recursive push.
git 子模块本身就是一个项目。因此，子模块的分支策略是通过与所有分支决策相同的考虑因素来定义的。子模块会并发开发吗？您想在不污染 master 历史记录的情况下回退更改吗？是的，测试也可能是一个考虑因素，但子模块的目标应该是它可以在其他项目中正确地重用。
我有几个使用共享子模块的项目，该子模块在处理多分支主项目时进行扩展。我很少看到需要分支子模块。但有时当然是有的。
A git submodule is a project by itself. So the policy for branching the submodule is defined by the same considerations as for all branching decisions. Will there be concurrent development of the submodule? Will you want to rewind the changes without polluting the history of master? Yes, testing may also be a consideration, but it should be the goal of a submodule that it can be reused properly in other projects.
I have a couple of projects using a shared submodule, which extends while working on the multi-branched main projects. I rarely see the need to branch the submodule. But sometimes of course there is.