git branching advanced usage, rebase from upstream branch

Here is my current situation (which may have already been messed up, as I see HEAD might be in a weird place):

$ git log --all --decorate --oneline --graph * 7aec18c (upstream/dev/br-1) more updates * b83c3f8 more updates * 4cf241f update file-a * 200959c update file-a from main * dc45a94 (upstream/master, master) update file-a from main | * ce2a804 (origin/dev/br-2) update file-a | * 0006c5e (HEAD -> dev/br-1, origin/dev/br-1) more updates | * cdee8bb more updates | * 85afa56 update file-a |/ * 2f5eaaf (origin/master, origin/HEAD) add file-a 

OK, I might draw this horizontally as:

A <-- origin/master |\ | B--C--D <-- dev/br-1 (HEAD), origin/dev/br-1 \ \ \ E <-- origin/dev/br-2 \ F <-- master, upstream/master \ G--B'-C'-H--I <-- upstream/dev/br1 

A = 2f5eaaf add file-a; B = 85afa56 update file-a; and so on. I picked the later ones to be the "primes" based on subject lines, although that might be backwards: perhaps the one labeled B should be B' for instance. It seems likely that despite the same subject line for commits B and E, they have different patch-IDs (do different things to file-a), and it's hard to say whether matching up the two "more updates" commits here (calling the second one on the bottom row C') was right.

(Note that there's no dev/br2 here.)

But let's go back to this:

[We start with]

A--B--C--D <-- master (upstream) \ E--F--G <-- dev/br-1 (upstream) \ H--I--J <-- dev/br-2 (myown) 

I reformatted this slightly into my own preferred style (two dashes between commits, or one if using a prime marker to indicate that it's a copy).

The ultimate goal is to place myown

H--I--J <-- dev/br-2 

branch on top of the newly rebased G', in my own repo, after catching up with upstream. I.e., in my own repo, in the end, it should look like this:

A--B--C--D <-- rebased master (upstream) \ E'-F'-G' <-- rebased dev/br-1 (upstream) \ H'-I'-J' <-- rebased dev/br-2 

The commits that must be copied are precisely E-F-G-H-I-J (in that order).

If you have all six commits in your own repository (plus of course the four A-B-C-D commits), then—ignoring the desired labels for a moment—all we need to do is convince Git to copy, as by cherry-picking, the six commits in question.

The two options for doing this are:

• git cherry-pick, which leaves both the originals and the copies for us to find easily; or
• git rebase, which does the copying, then moves one (1) branch name around for us.

Moving one branch name is insufficient. It's not particularly harmful and we could allow Git to do it, but let's just do this directly with cherry-pick. We'll start by checking out the commit onto which everything should land, creating a new branch name:

git switch -c copied <hash-of-D> 

or:

git switch -c copied --no-track upstream/master 

(assuming upstream/master names commit D). Then:

git cherry-pick <hash-of-D>..<hash-of-J> 

or:

git cherry-pick upstream/master..dev/br2 

(again the two names used here are just ways of typing in the raw commit hash IDs without having to type in raw commit hash IDs). The two-dot syntax here means any commits reachable from the second specifier, excluding all commits reachable from the first specifier, so this means commits from J all the way back to the root, minus commits from D all the way back to the root which means E-F-G-H-I-J.

The result of this copying would be:

 E'-F'-G'-H'-I'-J' <-- copied (HEAD) / A--B--C--D <-- master (upstream) \ E--F--G <-- dev/br-1 (upstream) \ H--I--J <-- dev/br-2 (myown) 

Now that we have the commits we want, we merely need to place the particular labels. Since one or more of these labels will point to commit G', it helps to redraw the above with H'-I'-J' on a row of its own:

 H'-I'-J' <-- copied (HEAD) / E'-F'-G' / A--B--C--D <-- master (upstream) \ E--F--G <-- dev/br-1 (upstream) \ H--I--J <-- dev/br-2 (myown) 

The labels we want moved are:

• dev/br1, maybe; it should point to G';
• upstream/dev/br1—but this is our copy of upstream's dev/br1, so we don't move it directly, we have the remote named upstream move theirs so that our Git updates our memory of their name;
• origin/dev/br1: this is just like upstream/dev/br1;
• dev/br2: this should point to J'; and
• myown/dev/br2 or maybe origin/dev/br2, but once again this is our Git's memory of some other repository's branch name, so we have to convince that other Git repository to move their name.

To move our own dev/br1, we can simply use git branch -f now:

git branch -f dev/br1 copied~3 

for instance. Since the name copied selects commit J', and the ~3 suffix means "move back three first-parents", that will select commit G'. The -f means force and causes our Git to move our dev/br1.

To move upstream's dev/br1 and cause our upstream/dev/br1 to move, we now need to git push --force-with-lease or similar to upstream, which also assumes that we have permission (on whatever system hosts upstream: Git itself doesn't "do" permissions, but sites like GitHub and others do, for obvious reasons). The --force-with-lease tells our Git to verify that their dev/br1 still points where we expect; if we're sure that this will be the case, we can use plain --force. Either way the command is, or resembles:

git push --force-with-lease upstream dev/br1 git push --force-with-lease origin dev/br1 

which uses the fact that we forced our br1 to point to G'.

The same process applies to making the various names point to H', except that now we can use the name copied:

git branch -f dev/br2 copied git push --force-with-lease origin dev/br2 

Once we have done all this, we can switch to dev/br2 or whatever and delete the extra branch name copied. It existed only so that we had a nice simple way to find commit H' after all the copying.

The key here is to understand that the names are largely irrelevant. All that actually matters are the commits, which are identified by their hash IDs. The trick is that we find the commits using the names, so that makes the names relevant.

Alternatives

If you like, you can still do this with two git rebase operations. Since things are relatively simple, we don't need the fancy --onto for the first one (but we will need it for the second):

git switch dev/br-1 git rebase upstream/master 

This takes our starting point, which looks like this—note that I'm assuming things about the remote-tracking names this time:

A--B--C--D <-- upstream/master \ E--F--G <-- dev/br-1 (HEAD), upstream/dev/br-1 \ H--I--J <-- dev/br-2, origin/dev/br-2 

and copies E-F-G to new-and-improved E'-F'-G', placing them after commit D, as named by upstream/master:

 E'-F'-G' <-- dev/br-1 (HEAD) / A--B--C--D <-- upstream/master \ E--F--G <-- upstream/dev/br-1 \ H--I--J <-- dev/br-2, origin/dev/br-2 

Having made the three copies, git rebase yanked the name dev/br-1 off commit G and made it point to commit G' instead.

Now we will separately copy H-I-J:

git switch dev/br-2 git rebase --onto dev/br-1 upstream/dev/br-1 

Here we needed the --onto to tell Git:

• Don't copy commits from upstream/dev/br-1 backwards, i.e., don't copy commits G and earlier, but that's not where we want to put the copies!
• Put the copies after commit G', i.e., the newly updated dev/br-1.

The result of this is:

 H'-I'-J' <-- dev/br-2 (HEAD) / E'-F'-G' <-- dev/br-1 / A--B--C--D <-- upstream/master \ E--F--G <-- upstream/dev/br-1 \ H--I--J <-- origin/dev/br-2 

As with the first git rebase, Git did the copying of the commits found from the current branch name (i.e., J and back), excluding the commits we said not to copy (i.e., G and back), placing the copies wherever they go—this time that's separate from the "what not to copy" part—and then, having made the copies, git rebase yanked the name dev/br-2 to point to the final copied commit (J').

With the (local) repository's names now pointing to the copies, it's once again just a matter of using git push --force-with-lease or git push --force to get the other Git software, working with the two other repositories, to update their branch names, so that our own Git's memories in our remote-tracking names get updated.

(If you can't literally force-push to upstream or origin, you can still send the updated commits, e.g., via pull requests, but someone else will have to convince the other repositories to actually move their branch names to take in the new commits.)