GIT strategy in handling 30+ repositories

Question

I'm thinking of a GIT strategy in handling different build based on a master build. In need your opinion on how to effectively manage this large scale repo / super repo.

Basically I need a single repo that has a 30+ "sub" repos in it. The reason why I need to have this kind of setup is because sooner or later each build will have their own features that shouldn't affect other builds.

What i have in mind is to create a separate branch for each build. With this approach, it will require me to create a separate build folder with the "master build" source code in it.

The problem with this is how do I apply a new feature across the builds without redoing it? Is there anyway to do this? Does anyone knows an effective way of handling this? Thanks in advance!

Master Base Code -+-- build 1
                  |-- build 2
                  |-- build 3
                  |-- build n..

Scenario 1: Build features

Build 1

• Header section is carousel.
• Body have 2 columns

Build 2

• Header section is an image.
• Body have 1 column

Build 2

• Header section is a slider.
• Body have 1 column

-- after finishing the features, the client wants to implement Build 1 carousel in other builds ---

Scenario 2: Apply build 1 carousel across the the different builds

Build 1

• Header section is carousel.
• Body have 2 columns

Build 2

• Header section is carousel.
• Body have 1 column

Build 2

• Header section is carousel.
• Body have 1 column

This will become complicated in merging the "carousel" feature to other build because they have different base code.

Answer 1

You can try using git submodules for this.

Basically, within the base app, import each of repo1, repo2 ,.. rep30 as submodules.

Now, you can check out an updated tag on a specific submodule, while keeping all the other submodules versions same, and effectively create a corresponding build for the codebase.