Organizing Git Repo of Different Concurrent Versions

Question

I currently am working on a codebase that, over time, has grown into 4 different versions that are actively in production. This model is described below.

Production Version Models

Model A

• Core Fn'ality
• Feature A

Model B

• Core Fn'ality
• Feature A
• Feature B

Model C

• Core Fn'ality
• Feature C

Model D

• Core Fn'ality
• Feature B
• Feature C

As shown, all models have the same core functionality, which is 95% of the code, but differ by a few main features. Some updates will need to be applied to all models, while some models may need to receive their own independent changes without affecting the others. All of these currently originated over time from the same main branch, but the amount of single or one-off changes has produced a very messy git tree. The main has become model agnostic but also hard to manage when making changes to just a single model.

I've considered making each model have their own branch main/modelA, main/modelB, and so on. Would this be the right path to pursue? The only drawback I can currently think of is making a change to the all models would require changing all main branches independently, which could be unnecessarily tedious.

I've also thought about git submodules, but I've never used them before and don't have a strong grasp if this is their intended or ideal use case. Would appreciate any insight.

Answer 1

1. Everybody will have here own vision and opinion, you'll not get The Final Answer (tm)
2. Git's submodules are no-no choice (no brain, no luck), grok git subtree
3. Forget about branches (for ndependent logical units), think about linked repos:

• Common shared Core is repo
• Each Feature is repo
• Each Model is superset of repos (CoreM + Feature + Feature + ...)
• CoreM is fork of Core with at least 2 branches Upstream + Mods for Model-specific core changes