How do I deal with nested branches in git?

Question

Not sure what to Google for regarding this issue. The above should be my X question. My Y question is

How do you deal with a parent branch that is frequently rebased?

Let's say I have the following branches:

STACK-123 [origin/master: ahead 3]
STACK-456 [STACK-123: ahead 7]
STACK-789 [STACK-456: ahead 4]

Note that they also have this dependency chain

origin/master <- STACK-123 <- STACK-456 <- STACK-789

Essentially I want to treat all of them as a set of patches. But if any of them get rebased, the downstream branches still retain the old versions of the commits.

So let's say we have this list of commits:

STACK-123 (a, b, c, d) atop origin/master
STACK-456 (e, f, g) and implicitly (a, b, c, d) atop origin/master

If STACK-123 is rebased, we get:

STACK-123 (a', b', c', d') atop origin/master
STACK-456 (a, b, c, d, e, f, g) atop origin/master

Notice how STACK-456 keeps the old commits?

What workflow is there that just links the branch to a set of commits and doesn't encounter this problem after rebasing?

Short of manually repairing each branch.

(Also, well aware of the dangers of rebasing already-published commits, so please forego repeating. None of these branches are published/mainlined.)

Answer 1

You should only rebase local branches before pushing them out to the world. Having a shared repo which is regularly being rebased is simply the wrong way to use Git.

(Also, well aware of the dangers of rebasing already-published commits, so please forego repeating.)

But it's the correct answer.

Rebasing rewrites history. The set of commits on a rebased branch is effectively unrelated to the set of commits on your local branches that haven't seen the rebase. Rebasing is basically a shortcut for doing a bunch of related cherry-picks.

Merging & branching are the way you should be sharing code with git. Rebasing is meant to clean up your local work before exposing it to the world.