what's the proper way to work with Git Submodules

Question

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?

Answer 1

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.

Answer 2

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.