Middle-ground between submodules and branches?

Question

I just got around creating topic branches for my project\'s unfinished features, managed by Git. They are all very self-contained in such a way, that one topic branch doesn\

Answer 1

That notion of "composition" or "inheritance of configuration" is not supported in Git, as explained in the question "Flexible vs static branching". Only merges allow you to "compose" the exact set of files you want.

The submodule feature help you to identify a coherent set of file which must have its own life cycle and be tagged at its own pace. That is not the case of your features.

Your approach should remain a "system-based" one, where you develop, tag and merge the all system. If something evolves on the master branch, it needs to be merge on the feature branches.
If the features involve a different set of files that the ones modified in the master branch, that merge will be trivial. If not, you can follow mateusza's suggestion, using an intermediate branch to resolve the conflicts and evaluate the result of such a merge, while keeping the feature branch untouched.

Answer 2

Lets say you have branch master and bunch of branches: feature1, feature2, feature3...

$ git checkout feature1
$ git branch master-with-feature1
$ git checkout master-with-feature1
$ git merge master

Any time you make any changes to master or feature1 you can checkout to master-with-feature1 and merge them.