Git 히스토리를 언제, 어떻게 rewrite해야 하나요?

Question

Accepted Answer

Git은 히스토리를 **rewrite**할 수 있게 합니다 — commit을 amend, rebase, squash하거나 제거하여 — commit을 정리하거나 문제를 해결하기 위해. 강력하지만 신중하게 해야 합니다. **공유된** 히스토리를 rewrite하면 심각한 문제를 일으키므로, 그에 관한 규칙이 매우 중요합니다. ## 히스토리를 rewrite하는 방법 ```text git commit --amend → 가장 최근 commit 수정(메시지 또는 내용) git rebase -i → commit squash, reword, 재정렬, 편집, 삭제(대화형) git rebase → commit을 다른 base 위로 재생(선형 히스토리) git reset → branch 포인터 이동(버리기/uncommit) git filter-repo → 많은 commit rewrite(모든 히스토리에서 파일/비밀 제거) → 이 모든 것이 commit 해시를 바꿈(rewrite = 새롭고 다른 commit 생성). ``` ## 황금률 ```text ⚠️ push/공유된(다른 사람이 가질 수 있는) 히스토리는 절대 rewrite하지 말 것: → rewrite는 commit 해시를 바꿈 → 협업자와 히스토리가 갈라짐 → 그들은 옛 commit을 가짐; pull이 중복/충돌 생성; 혼돈 발생 → 모두가 고통스럽게 조정하도록 강요 → 심각한 혼란 ✓ 로컬, push하지 않은 commit만 rewrite(공유 전 정리). ✗ 공유 branch에서는 → REVERT(새 취소 commit)를 대신 사용, 안전함. ``` ## rewrite의 정당한 용도(로컬) ```text ✓ PR 열기 전 지저분한 WIP commit 정리(squash, reword) → 깔끔한 히스토리 ✓ push 전 마지막 commit의 실수 수정(amend) ✓ 공유 전 feature branch를 main과 선형/최신으로 유지(rebase) ✓ 실수로 commit된 비밀(SECRET) 제거(filter-repo) — 단, push되었다면 비밀은 ROTATE되어야 함(이미 노출됨; rewrite만으로는 불충분) ``` ## 공유 히스토리를 rewrite해야 한다면(드묾) ```text → 전체 팀과 조율(모두 멈추고 재동기화) → 신중하게 force-push: git push --force-with-lease(--force보다 안전 — 먼저 확인) → 모두가 rewrite된 히스토리로 reset/재clone해야 함 → 진정 필요할 때만(예: 유출된 비밀 제거) 합의하에 수행. ``` ## 왜 중요한가 Git 히스토리를 언제, 어떻게 rewrite할지 이해하는 것은 중요한 시니어 수준의 지식입니다. 히스토리 rewrite는 **강력하지만 위험**하고, 그 규칙 — 특히 공유 히스토리에 관한 — 을 이해하면 정당한 정리를 가능하게 하면서 심각한 문제를 방지하기 때문입니다. **rewrite하는 방법**(마지막 commit을 위한 amend, squash/reword/재정렬을 위한 interactive rebase, 선형 히스토리를 위한 rebase, reset, 대규모 변경을 위한 filter-repo)과 이 모든 것이 **commit 해시를 바꾼다**(새 commit 생성)는 점을 아는 것이 토대입니다. 가장 결정적으로, **황금률 — 공유/push된 히스토리는 절대 rewrite하지 말 것** — 을 이해하는 것이 필수적입니다. rewrite는 해시를 바꿔 (여전히 옛 commit을 가진) 협업자와 히스토리가 갈라지게 하여 중복, 충돌, 고통스러운 조정으로 이어지기 때문입니다. 공유 히스토리 rewrite는 이 규칙이 방지하는 심각한 혼란이며, 공유 branch에는 **revert**(안전한 새 취소 commit)가 올바른 접근입니다. **정당한 로컬 용도**(PR 전 WIP commit 정리, push 전 실수 amend, 공유 전 선형 유지를 위한 rebase — 모두 로컬, push하지 않은 commit에)를 이해하면 rewrite가 적절하고 가치 있을 때가 명확해집니다. 결정적인 보안 뉘앙스: **비밀이 commit되고 push되었다면**, 그것을 제거하기 위해 히스토리를 rewrite하는 것은 불충분합니다 — 비밀은 이미 노출되었고 **rotate**되어야 합니다(중요한 실제 보안 포인트). **공유 히스토리의 드문 필수적 rewrite를 처리하는 방법**(팀 조율, `--force` 대신 `--force-with-lease`, 모두 재동기화)을 아는 것은 성숙한 판단을 반영합니다. 히스토리 rewrite는 강력하지만 공유 히스토리에 오용하면 심각한 문제를 일으키고, 황금률, 정당한 용도, 안전한 관행을 이해하는 것이 책임감 있게 사용하는 데 필수적이므로, Git 히스토리를 언제, 어떻게 rewrite할지 이해하는 것은 중요한 시니어 수준의 지식입니다. 이는 안전 규칙(특히 공유 히스토리를 절대 rewrite하지 않기)을 이해하는 것이 실제 협업 재앙을 방지하는 주제로, 팀에서 Git을 다루는 시니어 역할에 기대되는 판단력을 반영합니다.