dupe-com/rebased

Rebased

Rebases the current branch onto origin/main and resolves conflicts as they appear, one rebase step at a time.

When to use

The user typed /rebased, or asked something like "rebase me on main", "rebase and fix conflicts", "get this branch up to date with main".

Pre-flight checks (run in parallel)

Before touching anything, gather state:

git status --porcelain=v1 -b
git rev-parse --abbrev-ref HEAD
git rev-parse --git-dir   # to detect in-progress rebase via $GIT_DIR/rebase-merge or rebase-apply

Decision matrix:

• Working tree dirty → stop and ask the user whether to stash, commit, or abort. Do not silently git stash — that hides their work.
• Already on main/master → stop and ask. Rebasing main onto itself is almost never what they want.
• Rebase already in progress (.git/rebase-merge or .git/rebase-apply exists) → skip the fetch/rebase-start step and jump straight to the conflict-resolution loop.
• Detached HEAD → stop and ask.

Execution

1. Fetch and start the rebase

git fetch origin main
git rebase origin/main

If it returns clean ("Successfully rebased"), report that and stop.

If it stops with conflicts, proceed to the loop.

2. Conflict-resolution loop

Repeat until rebase is complete or the user tells you to stop.

a. Identify what's conflicted:

git status --porcelain=v1
git diff --name-only --diff-filter=U

b. Understand the current rebase step. This is critical — the conflict is between their commit (the one being replayed, marked <<<<<<< HEAD in working-tree convention during rebase is actually the upstream / main side; >>>>>>> commit-sha is the branch side being replayed). Get context:

git log --oneline -1 REBASE_HEAD       # the commit being applied
git show --stat REBASE_HEAD             # what it tried to change
git log --oneline origin/main -5        # recent main commits for context

c. For each conflicted file:

1. Read the file to see the conflict markers.
2. Decide the right resolution by understanding both intents:
   • What was main trying to do? (git log -1 -p origin/main -- <file> for the most recent main change to this file)
   • What was the branch commit trying to do? (git show REBASE_HEAD -- <file>)
3. Edit the file to merge both intents — do not blindly pick one side. Common patterns:
   • Both sides added imports → keep both, deduped, in sorted order
   • Both sides edited the same function differently → combine the changes if they're orthogonal; ask if they conflict semantically
   • One side renamed/moved code the other side edited → apply the edit at the new location
   • Lock files (bun.lockb, package-lock.json, yarn.lock) → regenerate (bun install / npm install / yarn) rather than hand-merge
   • Generated files (migrations, snapshots) → regenerate from source
4. Remove all <<<<<<<, =======, >>>>>>> markers.
5. git add <file>.

d. Sanity-check the resolution before continuing:

• For TypeScript/JS, run the project's type checker on affected files if the change touches types or imports.
• For tests, don't run the full suite — too slow per step. Save that for after the rebase completes.

e. Continue the rebase:

git -c core.editor=true rebase --continue

The -c core.editor=true skips the commit-message editor. If a commit becomes empty (all its changes are now upstream), use git rebase --skip instead.

f. If --continue produces another conflict, loop back to step (a). Each rebase step is one commit being replayed, so you may go through this several times.

3. Post-rebase

When rebase finishes:

git status
git log --oneline origin/main..HEAD     # show what was replayed

Report back: how many commits replayed, how many files had conflicts, anything you regenerated (lock files, migrations).

Do not push. Pushing a rebased branch requires a force-push, which is destructive — confirm with the user first, and use --force-with-lease not --force.

Hard rules

• Never use git rebase --skip or --abort without asking — these throw away work.
• Never use git checkout --theirs/--ours blindly — these discard one side wholesale and almost always lose intent.
• Never resolve a conflict by deleting the file unless you have positive evidence the file was deleted on purpose on one side (check git log --diff-filter=D).
• Never bypass hooks with --no-verify. If a pre-commit hook blocks --continue, fix the underlying issue.
• Never force-push automatically. Always confirm.
• If the conflict resolution is non-obvious (e.g. both sides rewrote the same function with different intent), stop and ask the user rather than guessing.

Error recovery

• "could not apply ..." with no obvious conflict → check for renames; git status will show "both modified" vs "added by us/them". For a rename conflict, find the new path with git log --follow --name-status and apply the change there.
• Lock-file conflict that won't resolve cleanly → git checkout --theirs <lockfile> && <install-command> && git add <lockfile> (using "theirs" = the branch being replayed onto, i.e. main's lockfile as the base).
• Stuck and want to bail out → tell the user the state, then ask before running git rebase --abort. Their working tree will return to pre-rebase state.

Reporting

End with a one-line summary: Rebased <branch> onto origin/main: N commits replayed, M files had conflicts (resolved). Run tests before pushing.