Scenario
A colleague has a review:
main
└─ CoMy stacked reviews are based on main:
main
└─ X
└─ YI want X (and therefore Y) to depend on Co.
Desired result:
main
└─ Co
└─ X
└─ YStep 1: Fetch Colleague’s Review
Fetch the Gerrit patch set:
git fetch origin refs/changes/NN/CHANGE_NUMBER/PATCHSETGit stores the fetched commit in:
FETCH_HEADStep 2: Create a Temporary Branch (Optional)
Instead of using FETCH_HEAD directly:
git checkout -b co-base FETCH_HEADResult:
main
└─ Co (co-base)This makes later commands easier to read.
Step 3: Rebase the Stack onto Co
Suppose:
main
└─ X
└─ Y <-- current branchRun:
git checkout feature
git rebase --onto co-base mainMeaning:
Take all commits after main
(X and Y)
Replay them on top of co-base
(Co)Result:
main
└─ Co
└─ X'
└─ Y'Understanding --onto
Syntax:
git rebase --onto <new-base> <old-base>Example:
git rebase --onto co-base mainRead as:
Take commits after
mainand move them ontoco-base.
Do I Need -i?
Usually:
NoA normal rebase is sufficient.
Use interactive rebase only when you want to:
-
Edit commits
-
Reword commit messages
-
Squash commits
-
Split commits
-
Reorder commits
Examples:
git rebase -i maingit rebase -i co-baseResolving Conflicts
If conflicts occur:
# fix files
git add <fixed-files>
git rebase --continueAbort if necessary:
git rebase --abortPush Updated Reviews to Gerrit
After rebase:
git push origin HEAD:refs/for/mainAs long as the commits keep their original Change-Id lines:
X -> updates existing review X
Y -> updates existing review YNo new reviews will be created.
Mental Model
Before:
main
├─ Co
└─ X
└─ YAfter:
main
└─ Co
└─ X
└─ YThink of rebase as:
Lift commits X and Y off their old floor (main) and place them on a new floor (Co).
One review per branch
git checkout X
git rebase co-base
git checkout Y
git rebase X