Git 사용자가 merge와 rebase의 동작 원리를 구분함으로써 공유 커밋 히스토리 손상 방지

Context

개발자가 git rebase 명령어를 동작 원리 없이 기계적으로 따르다가 푸시된 공유 브랜치를 리베이스해 일주일간의 팀 히스토리를 덮어씀.

Technical Solution

• merge와 rebase의 근본적 차이 이해: merge는 두 브랜치의 팁을 부모로 하는 새 커밋을 생성해 히스토리를 보존하고, rebase는 현재 브랜치의 커밋들을 다른 브랜치 위에서 재생해 커밋 해시를 변경
• rebase의 황금 규칙 적용: 로컬 미푸시 커밋에만 rebase 수행하고, 푸시되어 팀과 공유된 커밋은 절대 rebase하지 않음
• interactive rebase 활용: git rebase -i HEAD~N으로 로컬 커밋을 푸시 전에 정리(squash, 메시지 수정, 순서 변경, 분할)
• 통합 워크플로우 수립: 로컬 작업 → 로컬 rebase -i로 정리 → main으로 rebase해 최신화 → 푸시 후 PR 오픈 → merge로 메인 병합

Key Takeaway

merge와 rebase는 경쟁하는 철학이 아닌 워크플로우의 서로 다른 단계에 맞춘 도구이며, 공유된 히스토리 재작성은 항상 실수지만 의도적인 히스토리 정리는 merge 커밋과 함께 깔끔한 기록을 남김.