Git rebase subbranches to other subbranch

Question

This may or may have not been answered already, but since I don't know what the exact terminology is for what I want to do, it'll be hard to find it via searching.

Here is my current git project layout:

master
  |
  |-branch-a
  |-branch-b
  |-branch-c

I've realized that there are cases where changes that I make to all three subbranches are similar enough that they should be applied on top of master. However, master is my "import branch", where I import updated code from external sources before I merge it into the subbranches.

So I think the best way to do this is to create a subbranch off of master, say fixes, and then have my subbranches:

master
  |
  |-fixes
      |
      |-branch-a
      |-branch-b
      |-branch-c

Once I do that, I'll have to somehow deconflict the existing branches with any code fixed in the fixes branch. But I think the hard part is rebasing my subbranches to the fixes branch without messing up my repo.

Of note, each of the subbranches contains code that needs to remain independent of the others. Basically development in parallel on different ideas. One or more might get merged later on down the road back into master. Assumingly, if I have no fixes that apply to all of the subbranches, then fixes is basically just a mirror of master.

How can I go about doing this?

Edit: Because I can't draw ASCII in comments, this is in response to user3236304's answer.

I think I see what you're getting at. I should instead orient my branches like this?:

master (core fixes go here)
  |
  |-upstream
  |
  |-branch-a
  |-branch-b
  |-branch-c

That way I can apply my own local core fixes onto master and use the upstream branch to track changes from upstream, merging them into my local branches as-needed?

Answer 1

I'd do this slightly different; master is your common integration work branch-{a,b,c} are specific release branches, and you maintain a specific 'upstream' branch, importing from said upstream.

The gain there is that you've got a specific area to continually fold changes into, building towards new releases- with the expectation that each branch-{a,b,c} is likely to be derivative (closest) to that common branch point.

Regarding managing the common branch, from the sounds of it you're doing occasional merges/cherry-picks; this works fine, and such a structuring makes it easy to occasionally do a rebase of the common to eliminate noise/dead CLs, minimizing the historical delta from the actual upstream.

Regardless of the approach, I suggest you take a step back and try to decide if you consider your work the true 'master' for others (they'll be pulling from you), or if you're a derivative of some other upstream. What I described works reasonably well if you're a derivative; if you're the 'master', then you'll probably want something different.