Git: merge와 rebase의 차이

사이드프로젝트 회의를 하는데 새로들어오신 분이 왜 merge방식을 사용하는지에 의문을 가지셨다.
스프린트 별로 브랜치를 파서 거기에 머지를 하는 방식보다 rebase를 하는게 훨씬 깔금한게 아닌지에 대한것이었다.

간단하게만 알고 있어서 완벽히 이해한게 맞는지는 모르겠지만 ! merge와 rebase의 차이점을 다시 한번 정리하고자 한다.

---

$git merge

merge는 두 개의 브랜치를 합쳐 새로운 커밋을 생성하는 명령어

브랜치 간의 공통 조상으로부터 양쪽의 변경 사항을 병합하고, 그 결과를 새로운 merge commit으로 남긴다.

✅ merge 결과

• 히스토리가 직관적이고, 변경 흐름을 그대로 보존
• 팀 협업 시, 누가 어떤 시점에 병합했는지가 명확히 드러남
• 하지만 merge commit이 많아질수록 히스토리가 복잡해질 수 있음.

---

$git rebase

rebase는 한 브랜치의 시작점을 다른 브랜치의 최신 커밋으로 옮겨서, 커밋 이력을 새로 쌓는 명령어

즉, “기반(base)”을 새로 설정한다는 뜻

✅ rebase 결과

• 커밋 이력이 직선(linear) 형태로 깔끔하게 정리
• merge commit이 생기지 않아 히스토리가 단순함
• 하지만 이미 push한 브랜치를 rebase하면 충돌이나 꼬임이 생길 수 있어, 공유된 브랜치에는 사용을 피해야 함.

---

merge vs rebase 비교

구분	merge	rebase
병합 방식	새로운 merge commit 생성	커밋을 재정렬하여 base 변경
히스토리 형태	분기(branch) 유지	직선(linear)
이력 보존	원래 브랜치 흐름 보존	재작성됨
충돌 처리	병합 시 한 번	커밋마다 발생 가능 (커밋 단위로 순차 적용하기 때문)
사용 시점	협업 중인 main 병합 시	개인 브랜치 정리 시

+ merge –squash

명령어	설명
git merge	브랜치의 이력을 모두 보존하며 합침
git rebase	이력을 다시 쌓아 linear하게 정리
git merge --squash	여러 커밋을 하나로 압축해서 병합

squash merge는 “이력은 깔끔하게, 결과만 남기고 싶을 때” 사용하는 병합 방식

---

🔹 어떤 걸 써야 할까?

• 협업 브랜치(main, develop 등): merge → 이력 보존이 중요하고, 협업 흔적을 남기기 좋음

• 개인 브랜치(feature, fix 등): rebase → 불필요한 병합 이력을 없애고 깔끔한 히스토리를 유지하기 좋음

하지만 master 대신에 bts-image에 병합하기 전에 master를 리베이스하면 rebase도 충분히 매력적인 명령어이다 !

---

마무리

• merge: 기록을 보존하며 합침
• rebase: 기록을 정리하며 합침

---

Reference

이 포스트는 아래 게시글의 정보 및 이미지가 사용되었습니다.

1. Merge vs Rebase

---

END