How to rebase back a bunch of chained pull requests?

Question

How do i cleanly rebase a bunch of pull requests that were forked from each other?

I have 3 pull requests that are "chained" from each other (A, B, C), all from a clean point of master. i.e. after i made remote branch A, i made some changes from A into a new branch B. I made a pull request in the diff between the two branches and called it pull request B.

since then, Master has changed (presumably).

pull request A is the "closest" to current master in that the changes from there are most likely rebase-able off of master. But i need to make some modifications to A and update my pull request (from code review). I assume i can rebase off of master easily with the pull request branch A.

What happens when i try to then rebase B back into the Master' (which has changes from A)? Am i suppose to first cherry pick from the updated A? How do i properly pick the changes from A (that B doesn't have) in a way that B then can be rebased into master?

At the end of the day, i just want changes A (along with new changes), B, C rebased into master so that the history of master is clean. What is the best way to do this?

(feel free to correct my terminology, i don't think "rebase into master" is correct. i'm just trying to say that i want to replay my changes onto master when i say "rebase into master")

Answer 1

Apparently, all you need to do is... make changes to your heart's content on A. rebase master from the new branch A and merge this all back into master (--no-ff).

then rebase master from B, and the changes are in!! git does a very clever 3-way merge when replaying changes has failed. so it's incredibly easy to have all the changes you want from both the new A, and master on to branch B or new B.

repeat steps as necessary.

if you do run into duplicate commits, just do git rebase --skip like it tells you :)

Answer 2

So, I think this is how you've set up your branches, but correct me if this is wrong:

  master-with-new-commits
 /
/
master-old - A - B - C

You said you want to rebase A onto master, and then propagate that through the chain of branches, is that correct? If it is, then you simply use rebase multiple times for each branch, rebasing each one on top of its rebased parent, like so:

git rebase --onto <new-base> <old-base> <branch>
git rebase --onto master-with-new-commits master-old A
git rebase --onto new-A A@{1} B
git rebase --onto new-B B@{1} C

The branch@{1} syntax in this case simply means the state of branch at its 1st previous position, i.e. before it was rebased (assuming the rebases applied cleanly and didn't have any conflicts). If there were conflicts, you may simply use the commit sha of the old bases for each branch instead of the branch@{1} syntax.

After you have done all the rebasing, you should have the following:

  master-with-new-commits - new-A - new-B - new-C
 /
/
master-old - A - B - C