Git rebase vs merge: 초보자를 위한 핵심 차이점과 선택 가이드

Git rebase vs merge: 초보자를 위한 핵심 차이점과 선택 가이드

Git을 처음 배울 때 merge는 그냥 쓰다가, rebase라는 단어를 처음 보는 순간 멈칫했던 경험이 있을 거다. 뭔가 위험해 보이는 이름, 잘못 썼다가 커밋 히스토리를 날릴 것 같은 느낌. 실제로 rebase로 팀 저장소를 한 번 꼬아본 사람이라면 그 공포감이 이해될 것이다.

그런데 2026년 기준으로 대부분의 현업 팀은 이 둘을 명확하게 구분해서 쓰고 있다. merge를 완전히 버리는 것도, rebase만 고집하는 것도 아니다. 언제 어떤 걸 써야 하는지 판단하는 기준만 잡으면 두 가지 모두 편하게 쓸 수 있다. 이 글에서 그 기준을 정리해 본다.

---

merge와 rebase, 뭐가 다른가

이 두 명령어는 공통된 목적을 가진다. 한 브랜치의 변경사항을 다른 브랜치에 통합하는 것이다. 다만 그 방식이 완전히 다르다.

merge는 두 브랜치의 변경사항을 하나로 합치면서 병합 커밋(merge commit) 을 새로 만든다. 즉, feature 브랜치를 main에 병합하면 "Merge branch 'feature' into main"이라는 커밋이 하나 추가된다. 히스토리를 보면 두 브랜치가 합쳐지는 분기점이 명확하게 남는다.

rebase는 다르다. 리베이스(rebase)란 말 그대로 "베이스(base)를 다시 지정한다"는 뜻이다. 쉽게 말하면 내 브랜치에서 만들었던 커밋들을 통째로 떼어내서, 다른 브랜치의 최신 커밋 위에 새로 올려 붙이는 방식이다. 결과적으로 히스토리에는 마치 처음부터 하나의 브랜치에서만 작업한 것처럼 일직선 구조가 만들어진다.

코드로 보면 다음과 같다:

# merge 방식
git checkout main
git merge feature
# → 병합 커밋이 하나 생김

# rebase 방식
git checkout feature
git rebase main
# → feature 브랜치의 커밋들이 main 최신 커밋 위로 재배치됨

결과가 담긴 코드 자체는 동일할 수 있지만, 커밋 히스토리의 모양이 완전히 달라진다. 이게 핵심 차이다.

중요한 건 rebase를 실행하면 기존 커밋을 그대로 옮기는 게 아니라는 점이다. 내용은 같지만 새로운 커밋 해시(고유 ID)를 가진 커밋이 새로 생성된다. 그래서 이미 원격 저장소에 push된 커밋을 rebase하면 충돌이 발생하고, 나중에 git push --force를 써야 하는 상황이 생긴다. 이 부분이 초보자들이 가장 많이 실수하는 지점이다.

---

merge를 쓰면 히스토리는 어떻게 보이나

merge 방식의 가장 큰 특징은 히스토리의 진실성이다. 언제, 어느 브랜치에서, 누가 무슨 작업을 했는지 그대로 보인다.

예를 들어 main 브랜치에서 feature/login과 feature/signup이라는 두 브랜치가 동시에 진행됐다고 하자. 두 브랜치를 순서대로 main에 merge하면 히스토리 그래프는 Y자 모양으로 갈라졌다 다시 합쳐지는 구조가 반복된다. 처음 보면 복잡해 보이지만, 어떤 작업이 언제 병합됐는지 정확하게 추적할 수 있다.

*   commit abc123 (Merge branch 'feature/signup')
|\
| * commit def456  feat: 회원가입 폼 UI 추가
| * commit ghi789  feat: 회원가입 API 연동
|/
*   commit jkl012 (Merge branch 'feature/login')
|\
| * commit mno345  feat: 로그인 처리 로직
|/
*   commit pqr678  init: 프로젝트 초기 설정

히스토리가 복잡해 보이는 건 사실이다. 특히 브랜치가 많은 대규모 프로젝트에서는 git log --graph가 읽기 어려울 정도로 얽히는 경우도 있다. 이 부분은 merge의 단점으로 자주 언급된다.

반면 merge의 강점은 비파괴적이라는 점이다. 기존 커밋을 변경하지 않고, 분기와 합류의 시점이 그대로 남는다. 그래서 나중에 특정 시점으로 롤백하거나 문제를 추적할 때 훨씬 안전하다. 협업 중에 "이 버그가 언제 들어왔지?" 하고 추적할 때 merge commit이 있으면 오히려 도움이 된다.

팀 협업 관점에서 merge는 실수에 강하다. 실수로 merge해도 git revert로 되돌릴 수 있고, 히스토리를 건드리지 않으니 다른 팀원의 작업에 영향이 없다.

---

rebase를 쓰면 히스토리가 어떻게 달라지나

같은 작업을 rebase로 처리하면 히스토리가 완전히 다른 모양이 된다.

* commit abc123  feat: 회원가입 API 연동
* commit def456  feat: 회원가입 폼 UI 추가
* commit ghi789  feat: 로그인 처리 로직
* commit jkl012  init: 프로젝트 초기 설정

일직선이다. 병합 커밋 없이 마치 처음부터 하나의 브랜치에서 순서대로 작업한 것처럼 보인다. git log를 읽기가 훨씬 쉽고, 누가 어떤 작업을 했는지 커밋 메시지만 보면 파악이 된다.

rebase의 또 다른 장점은 main 브랜치의 최신 변경사항을 내 feature 브랜치에 쉽게 반영할 수 있다는 점이다. 내가 작업하는 동안 main에 다른 커밋이 쌓였다면, git rebase main을 실행하면 내 커밋들이 main의 최신 커밋 위에 새로 올라간다. 결과적으로 충돌을 미리 처리할 수 있고, PR을 올릴 때 더 깔끔한 상태가 된다.

# main에 새 커밋이 생겼을 때, feature 브랜치를 최신 상태 위로 재배치
git checkout feature/login
git rebase main

# 충돌이 있으면 해결 후
git add .
git rebase --continue

그러나 이 깔끔함에는 트레이드오프가 있다. 히스토리를 직선으로 만들기 위해 커밋 해시가 바뀌는데, 이미 원격 저장소에 push된 커밋을 rebase하면 다른 팀원의 로컬 저장소와 히스토리가 불일치한다. 이걸 억지로 맞추려면 --force-with-lease 옵션으로 강제 push를 해야 하고, 이 과정에서 팀원이 잘못 판단하면 커밋을 잃을 수 있다.

Atlassian Git 공식 가이드에서도 이 점을 강조한다. "공유 브랜치에 push된 커밋은 절대 rebase하지 않는다" — 이게 rebase를 안전하게 쓰기 위한 핵심 규칙이다.

---

언제 merge를 쓰고 언제 rebase를 쓰나

검색 결과와 현업 팀들의 사례를 보면, 2026년 시점에서 대부분의 팀이 하이브리드 방식을 사용한다. merge와 rebase를 상황에 따라 나눠 쓴다는 뜻이다.

정리하면 다음 기준으로 판단하면 된다.

rebase를 쓰는 상황
- 아직 push하지 않은 로컬 커밋을 정리할 때
- feature 브랜치를 main의 최신 상태와 맞출 때 (PR 열기 전)
- 커밋 메시지가 지저분한 걸 interactive rebase로 정리할 때
- 개인 작업 브랜치에서만 작업하고 있을 때

merge를 쓰는 상황
- PR을 main이나 develop에 통합할 때
- 여러 명이 같은 브랜치에서 작업하고 있을 때
- 배포 이력이나 기능 단위 추적이 필요한 프로젝트
- rebase에 익숙하지 않은 팀원이 있을 때

squash merge를 쓰는 상황

squash merge는 merge의 일종인데, feature 브랜치의 여러 커밋을 하나로 압축해서 main에 병합하는 방식이다. "fix typo", "lint 수정", "리뷰 반영" 같이 의미 없는 커밋이 여러 개 쌓였을 때 유용하다. 최근 GitHub PR 통합 전략에서 가장 많이 선택되는 방식 중 하나다.

# squash merge
git merge --squash feature/login
git commit -m "feat: 로그인 기능 구현"

현업에서는 보통 이런 흐름이다. 로컬에서 rebase로 정리 → PR 오픈 → 리뷰 완료 후 squash merge 또는 merge commit으로 통합. 두 가지 명령어를 역할에 맞게 나눠 쓰는 방식이다.

---

interactive rebase: 커밋 히스토리 정리 도구로 쓰기

rebase는 단순히 브랜치를 이동시키는 것 외에도 interactive rebase라는 강력한 기능을 제공한다. 커밋 히스토리를 직접 편집할 수 있는 기능이다.

# 최근 3개의 커밋을 편집 모드로 열기
git rebase -i HEAD~3

실행하면 에디터가 열리고 커밋 목록이 보인다.

pick a1b2c3 feat: 로그인 폼 추가
pick d4e5f6 fix: 오타 수정
pick g7h8i9 wip: 임시 저장

각 커밋 앞의 키워드를 바꿔서 다양한 작업을 할 수 있다.

• pick → 그대로 유지
• squash (또는 s) → 이전 커밋과 합치기
• reword (또는 r) → 커밋 메시지만 수정
• drop (또는 d) → 해당 커밋 삭제

실무에서 가장 자주 쓰는 건 squash다. PR 리뷰 과정에서 "수정사항 반영", "오타 수정", "테스트 추가" 같은 자잘한 커밋이 쌓이면, PR을 합치기 전에 이를 하나의 의미 있는 커밋으로 합쳐서 히스토리를 깔끔하게 만들 수 있다.

주의할 점은 interactive rebase도 커밋 해시를 바꾼다는 것이다. 이미 push된 브랜치에서 이 작업을 하면 force push가 필요해진다. 혼자 작업하는 feature 브랜치에서만 사용하는 것이 안전하다.

---

초보자가 자주 하는 실수와 대처법

Git을 처음 배우는 사람들이 rebase에서 가장 많이 하는 실수 몇 가지를 짚고 간다.

실수 1: main 브랜치에서 rebase를 실행한다

# 위험한 상황
git checkout main
git rebase feature/login  # ← main을 rebase하면 안 됨

main 브랜치는 팀 전체가 공유하는 브랜치다. 여기서 rebase를 하면 main의 커밋 해시가 바뀌고, 팀원 모두가 강제 push 문제를 겪게 된다. rebase는 항상 내 feature 브랜치에서 main을 대상으로 실행해야 한다.

# 올바른 방향
git checkout feature/login
git rebase main  # feature 브랜치의 커밋들을 main 위로 재배치

실수 2: rebase 중 충돌을 무시하고 abort하지 않는다

rebase 중 충돌이 발생했을 때 당황해서 처리를 중단하고 싶다면, 반드시 --abort 옵션으로 원래 상태로 돌아와야 한다.

# 충돌 해결 도중 중단하고 싶다면
git rebase --abort  # rebase 전 상태로 완전히 복원됨

이걸 모르고 그냥 브랜치를 전환하거나 다른 명령어를 실행하면 rebase가 중간에 걸린 상태가 된다. 나중에 다른 작업을 할 때 예상치 못한 오류가 발생한다.

실수 3: push된 브랜치를 rebase하고 일반 push를 시도한다

# 이미 push된 브랜치를 rebase한 후
git push origin feature/login
# → error: failed to push some refs

이 상황이 발생했다면 git push --force-with-lease를 쓴다. --force보다 안전한 버전으로, 원격 브랜치에 내가 모르는 커밋이 추가됐을 경우 강제 push를 막아준다.

git push --force-with-lease origin feature/login

단, 혼자 사용하는 브랜치에서만 이 옵션을 쓴다. 여러 명이 같은 브랜치를 사용 중이라면 force push 자체를 피해야 한다.

---

실전 팁: 팀 규모별 추천 전략

Git 전략은 팀 규모와 배포 방식에 따라 달라진다. 정답은 없지만, 자주 쓰이는 패턴을 참고하면 시행착오를 줄일 수 있다.

1인 개발 또는 사이드 프로젝트

복잡하게 생각할 필요 없다. merge를 기본으로 쓰다가, 커밋 히스토리가 지저분해지면 local에서 interactive rebase로 정리하는 방식이 편하다. rebase의 황금 규칙만 지키면 된다. push 전엔 자유롭게, push 후엔 건드리지 않는다.

소규모 팀 (2~5명)

feature 브랜치 전략을 쓴다. 각자 feature 브랜치에서 작업하고, PR 오픈 전에 git rebase main으로 최신 상태를 맞춘다. PR은 squash merge 또는 merge commit으로 통합한다. 병합 전략을 팀 규칙으로 명문화해두는 게 좋다.

중규모 이상 팀 (5명 이상)

GitHub Flow나 Gitflow 같은 브랜치 전략을 채택하고, PR merge 방식을 팀 단위로 통일한다. 이런 규모에서는 개인이 rebase를 잘못 쓰면 전체 히스토리에 영향이 생기므로, 공유 브랜치에서의 rebase를 명시적으로 금지하는 팀 컨벤션이 있는 경우가 많다.

CI/CD가 중요한 환경

자동화 파이프라인이 있는 팀은 merge 기반 전략을 선호하는 경향이 있다. merge commit이 있으면 정확히 어떤 커밋이 배포됐는지 추적하기 쉽고, 롤백 시 정확한 시점을 찾기도 편하다.

---

마무리: 두 가지를 같이 쓰는 게 맞다

merge와 rebase 중 하나만 골라야 한다는 생각부터 버리는 게 좋다. 이미 현업에서는 상황에 따라 둘 다 쓴다. rebase는 내 브랜치를 정리하는 도구고, merge는 완성된 작업을 통합하는 도구라고 역할을 나눠서 이해하면 판단이 쉬워진다.

핵심만 정리하면 이렇다. push 전에는 rebase로 정리하고, push 후에는 merge로 통합한다. 이 기준만 지켜도 대부분의 실수를 피할 수 있다.

rebase가 아직 낯설게 느껴진다면 interactive rebase 기능은 잠깐 뒤로 미뤄도 된다. 먼저 git rebase main으로 feature 브랜치를 최신 상태로 맞추는 것부터 익히고, 나중에 히스토리 정리가 필요해지면 그때 git rebase -i를 배우는 순서가 자연스럽다.

이런 사람한테는 merge만으로 충분하다. 1인 프로젝트거나 히스토리 가독성보다 안전성이 우선인 팀, 혹은 Git 자체가 아직 낯선 상황이라면 merge를 기본으로 쓰고 rebase는 나중에 천천히 배워도 늦지 않다.

반면 rebase가 확실히 빛을 발하는 상황은 따로 있다. 커밋 히스토리가 코드 리뷰나 배포 추적에 직접 활용되는 팀, PR 단위로 깔끔한 히스토리를 유지하고 싶은 경우, interactive rebase로 커밋을 직접 관리하고 싶은 사람이라면 rebase를 익혀두면 확실히 쓸모가 있다.

---

Sources:
- 병합 및 리베이스 비교 | Atlassian Git 자습서
- Git Rebase vs Merge — What's the Difference and When to Use Each (2026)
- 3.6 Git 브랜치 - Rebase 하기 | git-scm.com
- Git Merge vs Git Rebase: Pros, Cons, and Best Practices | DataCamp
- Git Rebase vs Merge: Differences, Use Cases and Best Practices 2026
- Merge vs Rebase: Choosing the Right Git Strategy for Your Team
- Git Workflow Best Practices 2025: Team-Proven Strategies - DEV Community