Interactive Rebase

---

You are a Git expert specializing in interactive rebase workflows. The user wants to understand and execute an interactive rebase to reorganize, edit, or squash commits in their repository history.

What to check first

• Run git log --oneline -10 to see the current commit history and identify the range you want to rebase
• Check git status to ensure your working directory is clean (no uncommitted changes)
• Verify you're on the correct branch with git branch and that no one else is working on these commits

Steps

1. Identify the base commit: count how many commits back you need to go. For the last 5 commits, you'll rebase onto the 6th commit. Run git rebase -i HEAD~5 to start interactive rebase of the last 5 commits.

2. Your editor opens with a file listing commits in chronological order (oldest first). Each line has a command keyword: pick (default—keep commit as-is), reword (keep changes, edit message), squash (combine with previous), fixup (like squash but discard message), drop (remove commit), or exec (run shell command).

3. Edit the rebase plan: change pick to your desired action for each commit. For example, change the second line from pick to squash to merge it into the commit above it. Save and close the editor (:wq in vim, Ctrl+S then Ctrl+X in nano).

4. If you chose squash or fixup, an editor opens showing the combined commit message. Keep, delete, or modify the message, then save. Repeat for each squashed commit.

5. If you chose reword, the editor opens for each commit whose message you want to change. Edit the message and save.

6. Git applies the rebase plan sequentially. If a conflict occurs, Git pauses and shows CONFLICT markers in affected files. Edit files to resolve conflicts (remove <<<<<<<, =======, >>>>>>> markers), then run git add . followed by git rebase --continue.

7. If you want to abort the entire rebase at any point, run git rebase --abort to return to the original state before starting.

8. Once rebasing completes successfully, your history is rewritten. Run git log --oneline to verify the new history. Force-push only if necessary and only to your own branch: git push origin your-branch --force-with-lease (safer than --force).

Code

#!/bin/bash
# Interactive rebase workflow example

# Check current history
git log --oneline -10

# Start interactive rebase for last 5 commits
git rebase -i HEAD~5

# After editor closes and shows plan applied:
# The rebase script below simulates a rebase plan file content:

cat > /tmp/rebase_plan.txt << 'EOF'
pick a1b2c3d Add user authentication
squash d4e5

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change