Interactive Git Rebase | pick· squash

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.

---

자주 묻는 질문 (FAQ)

Q. 이 내용을 실무에서 언제 쓰나요?

A. Use git rebase -i to edit commits: pick, squash, fixup, reword, edit, resolve conflicts, and recover with reflog—practic… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

Q. 선행으로 읽으면 좋은 글은?

A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.

Q. 더 깊이 공부하려면?

A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.

---

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

• Git 브랜치와 병합 | ‘merge conflict 났어요’ 충돌 해결 방법 (branch, merge)
• Git 되돌리기 | ‘실수한 커밋 취소하고 싶어요’ reset·revert·rebase 차이
• [Git Merge Conflict Resolution Case Study](/en/blog/git-case-study-01-merge-conflict-resolution/

---

이 글에서 다루는 키워드 (관련 검색어)

Git, Rebase, Interactive, Squash, Fixup, History 등으로 검색하시면 이 글이 도움이 됩니다.