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't directly relate to another topic branch. All branches, however, have some common ground, the master branch, which is the core of the system, the topic branches just extend the features in the master branch.

If I've understood correctly, if I do something in the master branch that affects (m)any topic branches (say, change the API used to communicate between the core and the individual features) that change doesn't propagate to the topic branches automatically, so that the branches could be fixed accordingly. The changes would need to be manually merged or cherry-picked into the other branches.

I understand that using submodules would achieve this. The submodules lead, however, to too much separation between the main project and the would-be feature projects, mainly because the features aren't self-sustaining. They rely on the core.

So, what I'm looking for is some kind of method to say that certain files/directories are unique to a certain branch, everything else comes from a main branch. Lacking a better analogy, speaking in Photoshop terms, I want master to be the Background-layer, and each topic branch would be a partly-transparent image layer on top of it, with some unique contents.

Answer 1

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.

Answer 2

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.