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?
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.