Interactive Git Rebase | pick, squash, fixup, Conflict Resolution, Recovery

Introduction

Git interactive rebase (git rebase -i) is the main tool for reordering, editing messages, and squashing commits on a local branch. Before opening a PR, squashing “WIP” or typo-only commits with fixup is a common pattern.

If you rewrite commits already pushed, history diverges—always align with team rules and force-push policy. This post walks through pick, squash, fixup, reword, and edit, plus conflict resolution and recovery, matching searches for Git rebase interactive conflicts.

---

Table of contents

1. Why interactive rebase
2. Basics: commands and editor tokens
3. Advanced: autosquash and partial staging
4. Compare vs merge
5. Real-world cases
6. Troubleshooting
7. Wrap-up

---

Why interactive rebase

• pick: keep the commit as-is.
• reword: keep the commit but rewrite the message.
• edit (e): stop at that commit to change content or split commits.
• squash (s): combine with the previous commit and edit the combined message.
• fixup (f): combine with the previous commit but discard this message (typical for “address review” noise).
• drop (d): remove the commit.

Execution order is top to bottom in the editor—oldest to newest. Reordering lines changes apply order.

---

Basics: commands and editor tokens

Clean up the last N commits

# Interactive rebase for the last 3 commits
git rebase -i HEAD~3

Example editor:

pick abc1234 feat: login API
pick def5678 fix: typo
pick fed9012 wip

# Rebase ...

Change fed9012 to fixup to absorb into the previous commit, or squash to merge messages.

After save/exit, squash/fixup may open a message editor.

Reword only

git rebase -i HEAD~2
# Change the first line to reword and save

Edit commit contents

git rebase -i HEAD~2
# Change the line you want to edit to edit

When stopped:

# edit files
git add -p   # partial staging if needed
git commit --amend --no-edit
git rebase --continue

Conflict resolution loop

# On conflict
git status
# after fixing files
git add path/to/file
git rebase --continue

# give up
git rebase --abort

Tip: During rebase, --theirs / --ours can be reversed in meaning—always know which side is which before using them.

---

Advanced: autosquash and partial staging

Auto-order fixup commits

git commit --fixup=abc1234
git rebase -i --autosquash abc1234^

--autosquash moves fixup commits right below the target. Many teams enable git config --global rebase.autoSquash true.

Squash many commits into one

git reset --soft HEAD~4
git commit -m "feat: integrate payment flow"

This replaces with a single new commit—same caution if already pushed. Interactive rebase keeps a clearer paper trail.

---

Compare vs merge

Topic	merge	rebase
History	Merge commits remain	Can stay linear
Shared branch	Safer	Rewriting history can confuse collaborators
Conflicts	One merge resolution	May resolve per commit

Rebase then push to a public branch needs team agreement; feature branches before PR are the safest default.

---

Real-world cases

• Pre-PR cleanup: absorb “WIP” and “fix lint” with fixup so reviewers see meaningful units.
• Commit conventions: reword to Conventional Commits types/scopes.
• Split a large commit: edit + git reset HEAD^ + multiple commits (advanced).

---

Troubleshooting

Rebase went wrong

git reflog
# reset to pre-rebase HEAD (e.g. HEAD@{5})
git reset --hard HEAD@{5}

reflog fixes most mistakes.

Continued by mistake

Use git reflog immediately and reset --hard. If already pushed, force-with-lease only with agreement.

Editor does not open

GIT_SEQUENCE_EDITOR="sed -i '' 's/^pick /squash /'"  # example—be careful

Many teams set GIT_EDITOR="code --wait" for VS Code.

Conflicts repeat

If multiple commits touch the same file, squash first, then rebase often hurts less.

---

Wrap-up

Interactive rebase makes local history readable; conflicts are the price of sequential replay. When changing shared commits, communicate and agree on force-push rules. Pair with Git branches and merge and Git revert / rebase.