interactive rebase는 어떻게 작동하나요?

Question

Accepted Answer

**interactive rebase**(`git rebase -i`)는 commit을 **rewrite, 재정렬, 합치기, 편집, 삭제**할 수 있게 합니다. 공유하기 전에 commit 히스토리를 정리하는 도구입니다. 지저분한 작업 중(work-in-progress) commit으로부터 깔끔하고 논리적인 히스토리를 만드는 강력한 도구입니다. ## interactive rebase 시작하기 ```bash git rebase -i HEAD~4 # 마지막 4개 commit을 대화형으로 rebase git rebase -i # 이후의 commit들을 rebase # → 적용할 동작과 함께 commit을 나열하는 에디터를 엶 ``` ## 동작 ```text pick abc123 Add login form # commit을 그대로 유지 squash def456 Fix typo # 이전 commit에 합침(메시지 병합) fixup ghi789 Fix another typo # 이전에 합침, 이 메시지는 버림 reword jkl012 Add validation # commit은 유지하되 메시지 편집 edit mno345 Refactor auth # commit을 amend하기 위해 일시 정지(내용 변경) drop pqr678 Debug logging # 이 commit을 완전히 삭제 # 줄을 재정렬하여 commit 재정렬 ``` 목록을 편집하여 commit별로 동작을 선택하고(줄을 재정렬하면 commit이 재정렬됨), Git이 그에 따라 재생합니다. ## 일반적인 용도 ```text ✓ 여러 WIP commit을 하나의 깔끔한 commit으로 SQUASH("wip", "fix", "oops" → 하나의 좋은 commit) ✓ 나쁜 commit 메시지 REWORD ✓ commit을 논리적 순서로 REORDER ✓ 원치 않는 commit(디버그 코드, 실수) DROP ✓ commit을 더 작은 commit으로 SPLIT(edit를 통해) → 결과: 지저분한 개발 commit 대신 깔끔하고 논리적인 히스토리. ``` ## 황금률은 여전히 적용됨 ```text ⚠️ interactive rebase는 히스토리를 REWRITE함(새 commit 해시): → 로컬, push하지 않은(UNPUSHED) commit에만 수행 — 공유/공개 히스토리에는 절대 금지 → 일반적 용도: push/PR 열기 전에 feature branch 정리 ``` ## 왜 중요한가 interactive rebase를 이해하는 것은 **깔끔한 commit 히스토리를 만드는 데** 가치 있으므로, 전문적인 Git 작업에 유용한 실무 지식입니다. 개발 중에 commit은 종종 지저분합니다. "wip", "fix typo", "oops" 같은 메시지를 가진 작업 중 commit, 디버그 commit, 비논리적인 순서 등입니다. **interactive rebase**는 공유 전에 이를 정리할 수 있게 합니다. 여러 지저분한 commit을 깔끔하고 논리적인 것으로 squash하고, 나쁜 메시지를 reword하며, commit을 합리적인 순서로 재정렬하고, 원치 않는 commit(예: 디버그 코드)을 삭제하며, commit을 나누어 지저분한 개발 히스토리를 깔끔하고 논리적이며 검토 가능한 시퀀스로 변환합니다. 이것이 중요한 이유는 깔끔한 commit 히스토리(좋은 commit 관행에서 다룬 것처럼)가 코드 리뷰를 쉽게 하고, 히스토리를 더 이해하기 쉽게 하며, (bisect를 통한) 디버깅을 더 효과적으로 만들기 때문입니다. 따라서 다른 사람이 작업을 보기 전에 정리하는 능력은 전문적인 Git 관행의 특징입니다. **동작**(pick, squash, fixup, reword, edit, drop, 재정렬)과 **일반적인 용도**(특히 매우 빈번한 필요인 WIP commit squash)를 이해하는 것이 실무 기술입니다. 결정적으로, **rebase의 황금률은 여전히 적용됩니다**. interactive rebase는 히스토리를 rewrite(새 해시)하므로 **로컬, push하지 않은 commit에만** 수행해야 합니다(공유 히스토리에는 절대 금지). 일반적인 용도는 push하거나 pull request를 열기 *전에* feature branch를 정리하는 것입니다. 깔끔하고 논리적인 commit 히스토리는 협업과 유지보수성에 가치 있고, 개발은 자연스럽게 interactive rebase로 공유 전에 정리할 수 있는(안전하게, 로컬 commit에) 지저분한 commit을 만들어 내므로, interactive rebase를 이해하는 것 — 동작, squash 같은 일반적 용도, 안전 규칙 — 은 전문 개발을 위한 가치 있고 실무적으로 관련된 Git 지식입니다. 이는 깔끔하고 검토 가능한 히스토리를 제시하는 강력한 도구로, 사려 깊은 Git 사용자를 구별 짓고 작업을 팀과 공유하기 전에 다듬는 데 일상적으로 사용됩니다.