Rebase Stack

1. Identify the Branches

# You should be on Branch B
git branch --show-current

# Fetch latest
git fetch origin

# See Branch A's recent commits
git log --oneline origin/branch-a -10

2. Find the Original Base Point

Find where Branch B originally diverged from Branch A:

# This shows the commit where Branch B was created from Branch A
git merge-base HEAD origin/branch-a

3. Rebase Using --onto

The --onto flag lets you transplant Branch B's unique commits onto the updated Branch A:

# Syntax: git rebase --onto <new-base> <old-base> <branch>
git rebase --onto origin/branch-a $(git merge-base HEAD origin/branch-a) HEAD

Or if you know the old base commit:

git rebase --onto origin/branch-a <old-base-commit> HEAD

4. Resolve Any Conflicts

If Branch A's changes conflict with Branch B's changes:

1. Resolve the conflicts in the affected files
2. Stage: git add <files>
3. Continue: git rebase --continue

5. Force Push

git push --force-with-lease origin branch-b

Example

# On branch-b, which was based on branch-a at commit abc123
# branch-a now has new commits

$ git fetch origin
$ git rebase --onto origin/branch-a abc123 HEAD
Successfully rebased and updated refs/heads/branch-b.

$ git push --force-with-lease origin branch-b

Alternative: Simple Rebase

If Branch B hasn't diverged much and you're okay with a linear history:

git rebase origin/branch-a

This works well when Branch A only added commits (no force-pushes or rebases).

Scenario 2: Rebase onto Main After Base Merges

Use when Branch A has been merged to main, and Branch B needs to be rebased onto main (removing the now-redundant Branch A commits).

When to Use

• Branch B was created from Branch A (not main)
• Branch A has been merged to main
• Branch B now shows as "diverged" from its remote
• PR for Branch B shows merge conflicts or "CONFLICTING" status
• git log shows commits from Branch A in Branch B's history

Workflow

1. Verify the Situation

# Check current branch status
git status

# See how the branch relates to main
git log --oneline --graph HEAD~20..HEAD

# Check if the PR is in a conflicting state
gh pr view --json mergeable,mergeStateStatus

If you see "mergeStateStatus": "DIRTY" or "mergeable": "CONFLICTING", proceed.

2. Fetch Latest and Start Rebase

git fetch origin main

# Start rebase onto main
git rebase origin/main

3. Handle Already-Merged Commits

When git tries to apply commits that are already in main (via the merged base branch), you'll see conflicts. These commits should be skipped, not resolved.

Signs a commit should be skipped:

• The commit message matches one from the merged PR
• Git shows "patch contents already upstream"
• Conflicts are in files that were part of the base branch's changes

For each conflicting commit that was already merged:

git rebase --skip

Git will automatically drop some commits with messages like:

dropping abc123 Some commit message -- patch contents already upstream

This is expected and correct.

4. Resolve Genuine Conflicts

If you encounter a conflict in code that is genuinely new to this branch:

1. Check if the conflict is from your branch's unique changes
2. Resolve the conflict manually
3. Stage the resolution: git add <files>
4. Continue: git rebase --continue

5. Force Push the Rebased Branch

git push --force-with-lease origin <branch-name>

6. Verify PR Status

gh pr view --json mergeable,mergeStateStatus
gh pr checks

The PR should now show:

• "mergeable": "MERGEABLE"
• "mergeStateStatus": "BLOCKED" (waiting for CI) or "CLEAN" (ready to merge)

Example

$ git rebase origin/main
Rebasing (1/15)
CONFLICT (content): Merge conflict in src/feature.py