Discusses approaches to structure a git repository for software that is customized for several clients

git-layout-for-client-customizations.txt

Consider a software that is customized for each client. It contains common components, modules, and
client-specific customizations thereof. For instance,

    Common
      + Common.ClientA
      + Common.ClientB
    ModuleA
      + ModuleA.ClientB
    ModuleB
      + ModuleB.ClientA
      + ModuleB.ClientB
    Main

There are three options for organizing a git repository:

1. Divide the repo into subrepos and pull them together selectively using submodules (in the case above
three repos: Common (+Modules), ClientA, ClientB or 5 repos: Common, ModuleA, ModuleB, ClientA, ClientB)
2. Put everything into one repo, but create separate branches (in the case above: Common (+ Modules),
ClientA, ClientB + for each master, develop, release, feature and hotifx branches [assuming a gitflow approach]).
3. Put everything into one repo and use different solutions or solution configurations to discern the clients

Regarding #1: A lot of discussion about submodule vs subtree. Still, the use case here is to get upstream
changes from ClientA repo back to Common. Otherwise it's very hard to hold "the common" together. Interestingly,
this is hardly discussed on the web where the use case seems to be to get downstream changes. Most agreed use
case for submodules is of embedding an external library that only needs occassional updating.
Advantage: every commit to common will have to be pushed to the common repository and thus those changes can
never diverge creating multiple different "common". Additionally, it allows to progress in different speeds,
e.g. ClientA needs new functionality in Common, but ClientB remains at older version for now.
Disadvantage: submodules are more difficult to work with and require special care (submodule update after pull,
wordy branching in case submodules needs to be branched as well)

Regarding #2: Each branch contains only exactly those projects that are required for each client. This makes
merging upstream changes a little bit more complex, because they'd have to be selective (merge --no-ff --no-commit
and removing client specific parts).
Advantage: Easier to work with because no submodules are involved.
Disadvantage: Lots and lots of branches in one single rep. Changes in the common of ClientA might not get merged upstream.

Regarding #3: A simple solution.
Advantage: Simple.
Disadvantage: Lots of unrelated changes in merges (e.g. branching for ClientA, but having to merge commits for
ClientB from master). Lots of code in e.g. ClientA release branch that is not meant to be compiled (all of
ClientB specialization). Difficult to give only selective access.