# Rebase

> Rebase the current branch.

- Skill: `raine/rebase` (Agent Skill)
- Install (CLI): `npx skillmds@latest add raine/rebase`
- Raw SKILL.md: https://api.skillmd.com/api/skills/raine/rebase/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: raine (https://skillmd.com/u/raine)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/raine/rebase

---


Rebase the current branch.

Arguments: $ARGUMENTS

Behavior:

- No arguments: rebase on local main
- "origin": fetch origin, rebase on origin/main
- "origin/branch": fetch origin, rebase on origin/branch
- "branch": rebase on local branch

Steps:

1. Check for uncommitted changes:
   - Run `git status --porcelain`
   - If there are changes, run `git stash push -m "rebase-temp"`
   - Remember to pop the stash after rebase completes
2. Parse arguments:
   - No args → target is "main", no fetch
   - Contains "/" (e.g., "origin/develop") → split into remote and branch, fetch
     remote, target is remote/branch
   - Just "origin" → fetch origin, target is "origin/main"
   - Anything else → target is that branch name, no fetch
3. If fetching, run: `git fetch <remote>`
4. Detect already-merged commits (see below)
5. Run: `git rebase <target>` (or `git rebase --onto` if stale commits found)
6. If conflicts occur, handle them carefully (see below)
7. Continue until rebase is complete
8. If workmux-base was used and pointed to a merged branch, update it to the
   target branch (strip remote prefix for the config value):
   ```
   git config branch.<branch>.workmux-base main
   ```
9. If changes were stashed in step 1, run `git stash pop`

Detecting already-merged base branches:

When a branch was based on another branch that was squash-merged into the
target, the old commits still appear in the branch history but their changes are
already in the target. A plain `git rebase` will try to replay them all, causing
repeated conflicts that need to be skipped one by one.

Before rebasing, detect this situation and use `--onto` to skip stale commits:

1. Check if workmux stored a base branch for the current branch:
   ```
   base=$(git config --get branch.$(git branch --show-current).workmux-base)
   ```
2. If a base branch is found and it's NOT the rebase target (e.g. base is
   `analytics-app-detail` but we're rebasing onto `origin/main`):
   - Check if the base branch has been merged into the target:
     ```
     git merge-base --is-ancestor <base> <target>
     ```
   - If it HAS been merged (exit code 0), find where our branch diverged from
     the base branch:
     ```
     fork_point=$(git merge-base <base> HEAD)
     ```
   - Then find the last commit on our branch that was part of the base branch
     (i.e. the last commit before our own work started):
     ```
     # The tip of the old base branch in our history
     last_stale=$(git rev-list --ancestry-path $fork_point..HEAD \
       --not <target> | tail -1)^
     ```
     Or more simply: the merge-base between the base branch tip and HEAD gives
     the fork point, and all commits between that and the first commit unique to
     our branch are stale. Use:
     ```
     git rebase --onto <target> <base> HEAD
     ```
     This replays only commits after the base branch tip onto the target.
   - If the base branch has NOT been merged, fall through to a normal rebase.
3. If no workmux base is found, fall back to heuristic detection: walk commits
   oldest-to-newest and check if each commit's file changes already match the
   target using `git diff --quiet`. Find the last stale commit and use
   `git rebase --onto <target> <last-stale-commit>`.
4. If no stale commits are detected by either method, use a plain
   `git rebase <target>`.

Handling conflicts:

- BEFORE resolving any conflict, understand what changes were made to each
  conflicting file in the target branch
- For each conflicting file, run `git log -p -n 3 <target> -- <file>` to see
  recent changes to that file in the target branch
- The goal is to preserve BOTH the changes from the target branch AND our
  branch's changes
- After resolving each conflict, stage the file and continue with
  `git rebase --continue`
- If a conflict is too complex or unclear, ask for guidance before proceeding