rebase-on-fresh-base-after-merge

Start the next change from a fresh base

When to use

You just landed a PR (or the user says "I merged it"), and you're about to make the next change in the same repo. The working tree is still on the feature branch that was merged, or on a stale local master / main.

Problem

Three related failure modes:

1. Branching off a stale base. Local master hasn't been fetched since the merge, so a new branch cut from it is missing the commits that were just merged upstream. The next PR will show a confusing diff (including files you didn't touch) or fail to merge cleanly.
2. Reusing the old feature branch. Appending new commits to the already-merged branch and pushing again creates a "PR #2 on the same branch" situation — GitHub may refuse to open it, or will show the old merged commits in the diff.
3. Uncommitted edits trapped on the wrong branch. You already made edits for the next task while still on the old branch; a naive git checkout master either fails or silently drags the edits along to a base that doesn't match them.

Symptom example:

$ git log --oneline origin/master..HEAD
fac933f Seed agent-skills with format spec and initial 7 skills   # already merged!

Solution

Standard recipe, safe with or without uncommitted edits:

# 0. (If you have unstaged edits for the next task) stash them
git -C <repo> stash push -u -m "wip-<next-task>"

# 1. Sync local refs with the remote
git -C <repo> fetch origin --prune

# 2. Find the real default branch — don't assume main or master
default=$(git -C <repo> symbolic-ref refs/remotes/origin/HEAD | sed 's@^.*/@@')

# 3. Fast-forward local default to origin
git -C <repo> checkout "$default"
git -C <repo> pull --ff-only origin "$default"

# 4. Cut the new branch from the fresh base
git -C <repo> checkout -b <new-slug>

# 5. Reapply the stashed edits (if step 0 happened)
git -C <repo> stash pop

# 6. Verify you're actually ahead of origin/$default by 0 commits
git -C <repo> log --oneline "origin/$default..HEAD"   # should be empty