피드로 돌아가기
Dev.toBackend
원문 읽기
I Thought I Understood Git. Then I Actually Learned the Difference Between Rebase and Merge.
Git 사용자가 merge와 rebase의 동작 원리를 구분함으로써 공유 커밋 히스토리 손상 방지
AI 요약
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 커밋과 함께 깔끔한 기록을 남김.
실천 포인트
팀 기반 Git 워크플로우에서 로컬 기능 브랜치 작업 시 `git rebase -i`로 WIP 커밋을 정리하고 `git rebase main`으로 최신화한 후 푸시하면, main 브랜치 히스토리는 merge 커밋으로 명확하게 보존하면서도 PR 내부는 깔끔한 커밋 시퀀스를 유지할 수 있다.