Merge와 Rebase의 정의
두 브랜치를 합치는 방법에는 크게 git merge와 git rebase가 있습니다. Merge는 두 브랜치의 변경 내용을 합쳐서 ‘병합 커밋’이라는 새로운 커밋을 만드는 방식입니다. 반면 Rebase는 내 브랜치의 커밋들을 통째로 들어서, 다른 브랜치의 최신 커밋 뒤에 다시 쌓아 올리는 방식입니다. 즉, 커밋의 ‘베이스(기준점)’를 바꾼다는 뜻에서 rebase라는 이름이 붙었습니다.
동작 원리와 예시
비유로 설명하면, Merge는 두 개의 책 내용을 합쳐서 ‘합본’이라는 새 책을 하나 더 만드는 것이고, Rebase는 내가 쓴 챕터들을 떼어내서 상대방 책 뒤에 이어붙이는 것과 비슷합니다. 결과물은 비슷해 보여도 역사(커밋 로그)가 남는 방식이 다릅니다.
예를 들어 main 브랜치에서 feature 브랜치를 만들어 작업했다고 가정해봅시다.
git merge main을 하면 feature 브랜치에 main의 변경 내용을 합치면서 ‘Merge branch main’ 같은 병합 커밋이 하나 추가됩니다. 커밋 로그가 두 브랜치의 흐름을 그대로 보여줘서 누가 언제 어떤 브랜치에서 작업했는지 추적하기 쉽습니다.git rebase main을 하면 feature 브랜치의 커밋들이 main의 최신 커밋 뒤로 재배치됩니다. 병합 커밋이 생기지 않아 로그가 마치 한 줄로 쭉 이어진 것처럼 깔끔해집니다.
단, rebase는 커밋의 해시 값을 바꾸기 때문에, 이미 다른 사람과 공유한 브랜치에서 사용하면 커밋 역사가 뒤틀려 충돌이 생길 수 있습니다.
실무에서 언제 무엇을 쓸까
실무에서는 상황에 따라 전략을 나눠 씁니다.
- 개인 작업 브랜치에서 커밋을 깔끔하게 정리하고 싶을 때는 rebase를 사용합니다. 예를 들어 PR을 올리기 전에
git rebase -i로 커밋을 정리하면 리뷰어가 보기 편한 히스토리를 만들 수 있습니다. - 이미 여러 사람이 공유하는 브랜치(main, develop 등)를 합칠 때는 merge를 사용합니다. 병합 커밋이 남아 있어야 ‘언제 어떤 기능이 통합됐는지’를 기록으로 남길 수 있기 때문입니다.
- 팀 컨벤션에 따라 ‘PR 병합 시 squash merge’를 쓰는 경우도 많은데, 이는 여러 커밋을 하나로 압축해 merge하는 방식으로 rebase의 깔끔함과 merge의 안전성을 절충한 방법입니다.
결국 핵심은 ‘공유된 히스토리는 함부로 바꾸지 않는다’는 원칙입니다. 내 로컬 브랜치를 정리할 때는 rebase, 여러 사람의 작업을 통합할 때는 merge를 기본값으로 생각하면 충돌과 혼란을 줄일 수 있습니다.