rebase-main

Files (1)

• SKILL.md

SKILL.md (first lines)

# Rebase Current Branch onto Main

Rebase the current working branch onto the latest `origin/main` (or `origin/master`) for a clean, linear commit history. Handle conflicts and produce a summary report.

## Your Task

Execute the following steps in order:

### 1. Pre-flight checks
1. Run `git rev-parse --abbrev-ref HEAD` to get the current branch name.
2. **Safety check**: if on `main` or `master`, **stop** and warn the user. Do NOT rebase the main branch.
3. Run `git status --porcelain` to check for uncommitted changes.
   - If there are uncommitted changes, **stop** and warn the user. Ask if they want to stash or commit first. Do NOT proceed with a dirty working tree.
4. Determine the main branch: check if `origin/main` exists (`git rev-parse --verify origin/main`). If not, fall back to `origin/master`.

### 2. Fetch and rebase
1. Run `git fetch origin` to get the latest remote state.
2. Run `git rev-list --count HEAD..{main-branch}` to see how many new commits are on main.
   - If **0 commits** incoming, report "Already up to date with {main-branch}" and stop.
3. Capture the incoming commit list BEFORE rebasing: `git log --oneline HEAD..{main-branch}`.
4. Run `git rebase {main-branch}`.
5. Capture the rebase output.

### 3. Handle conflicts
If the rebase stops due to conflicts:
1. Run `git diff --name-only --diff-filter=U` to list conflicted files.
2. For **each conflicted file**:
   a. Read the file to see the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`).
   b. Analyze the conflict:
      - **Theirs-only changes** (our side is unchanged around the conflict): accept theirs.
      - **Ours-only changes** (their side is unchanged around the conflict): accept ours.
      - **Both sides changed**: Use your best judgment based on the code context. Prefer combining both changes when they don't overlap logically. If the conflict is complex or ambiguous, **abort the rebase** (`git rebase --abort`), report the issue, and let the user handle it manually.
   c. Edit the file to remove conflict markers and apply the resolution.
   d. Run `git add {file}` to mark it resolved.
3. After all conflicts in the current step are resolved, run `git rebase --continue`.
4. Repeat steps 1-3 if the rebase stops again on subsequent commits.
5. If more than **3 conflict rounds** occur, **abort the rebase** (`git rebase --abort`) and report to the user that manual resolution is needed.

### 4. Post-rebase report
Generate a clear report with:

```
## Rebase Report: {current-branch} onto {main-branch}

### Summary
- **New commits from main:** {count}
- **Conflicts:** {count} ({list of files, or "None"})
- **Status:** {Rebased cleanly | Rebased with conflict resolution | Aborted}

### Commits from main
{list of commits from git log --oneline captured BEFORE the rebase}

### Conflict Resolutions (if any)
For each resolved conflict:
- **{filename}**: {brief description of what conflicted and how it was resolved}

### Notes
- Your local commits have been replayed on top of the latest main.
- If your branch was previously pushed, you will need to force-push: `git push --force-with-lease`
```

## Important

- **Never rebase `main` or `master`** — check the branch name first
- If there are uncommitted changes, **do not proceed** — ask the user first
- If a conflict resolution is ambiguous, **abort the rebase** rather than guessing wrong
- Always use `git rebase --continue` (never `--skip`) after resolving conflicts
- Use `--force-with-lease` (not `--force`) in the push reminder — it's safer
- After completion, do NOT push — leave that to the user, but remind them about force-push if needed
- If anything goes wrong mid-rebase, run `git rebase --abort` to return to the original state

From TJaenichen/claude-code-harness, MIT.

More from TJaenichen/claude-code-harness