Question

In my case, The super project is big enough so it consists of multiple artifacts. Let's say project A,B,C,D,E. They are different git projects. Now we need to work on two different releases, then it comes down to the problem how do we wanna do branching. I am coming from subversion world initially, if it's SVN, I would probably think about creating a super project and contain all the sub projects A,B,C,D,E, then I just branch away the super project.

But in terms of branching, conceptually, git has some difference from SVN. Just wondering in git world, normally what's the best practice for branching multiple git projects for different releases? I know submodules has been talked a lot, does it make sense to branch the projects individually?

Another question is that if the branching is done, how do we version the artifacts in different branches? if you have two branches, that will mean you will have different versions for all sub projects in two different branches, then you start to smell failure.

Was it helpful?

Solution

Since branches are very light-weight, you should not feel concerned about creating them for all subprojects that you have control over. Most of this work is wrapped up in a project called git slave. Dealing with git submodule foreach everywhere might get tedious and cause you issues should you forget to prefix your commands with it.

OTHER TIPS

Submodules or sub repositories is the way to go to split up a bigger project. Every submodule has it's own responsibility, version and branches.

So you have to ask yourself which repositories do you need to change and branch those. Maybe from the 10 submodules you only need to touch and branch one or two, unless it is a major refactoring, then you don't have choice.

You can branch everything with the following commands (run in the root of your main repo)

git checkout -b hacking_away
git submodule foreach git checkout -b hacking_away
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top