Git

중급 01. Merge vs Rebase 실무 선택 가이드

Merge와 Rebase의 결정적 차이, 실무에서 어떤 상황에 무엇을 선택해야 하는지, 그리고 커밋 트리가 어떻게 달라지는지 비교 예제

· 1min read · 4 views
중급 01. Merge vs Rebase 실무 선택 가이드

핵심 요약

Merge와 Rebase의 커밋 히스토리 차이점 비교, 실무 선택 기준 및 공용 브랜치에서 Rebase를 금지하는 Golden Rule 가이드

Git을 사용하면서 가장 많은 논쟁과 혼란이 일어나는 주제가 바로 "Merge를 써야 하는가, Rebase를 써야 하는가?"입니다. 프롬프트 상의 브랜치 표시(branch-name) $를 명시하여 두 명령어의 동작과 실무 선택 기준을 정리합니다.


1. 핵심 차이 한눈에 비교

비교 항목Merge (병합)Rebase (재배치)
동작 방식두 브랜치의 끝을 이어주는 새로운 Merge Commit을 생성내 커밋들을 대상 브랜치 최신 커밋 뒤로 한 줄로 이어 붙임
히스토리 모양브랜치가 갈라지고 합쳐진 분기선이 그대로 남음 (비선형)마치 처음부터 대상 브랜치에서 작업한 것처럼 깔끔한 1자 선형
커밋 해시 유지기존 커밋 해시가 100% 보존됨커밋들이 새로 생성되므로 커밋 해시(ID)가 변경됨

2. 시나리오 1: Merge 방식

동료들의 작업과 내 작업을 합치면서 명확한 합류 기록(Merge Commit)을 남기고 싶을 때 사용합니다.

# develop 브랜치로 이동
(feature/user-login) $ git switch develop
Switched to branch 'develop'

# feature 브랜치를 병합 (실무에서는 히스토리 보존을 위해 --no-ff 옵션 권장)
(develop) $ git merge --no-ff feature/user-login
Merge made by the 'ort' strategy.

3. 시나리오 2: Rebase 방식

내 작업 브랜치를 최신 상태로 갱신하면서 불필요한 머지 커밋 없는 깔끔한 1자 히스토리를 만들고 싶을 때 사용합니다.

# 내 작업 브랜치에서 실행
(develop) $ git switch feature/user-login
Switched to branch 'feature/user-login'

# develop의 최신 커밋 뒤로 내 커밋들의 베이스를 재배치
(feature/user-login) $ git rebase develop
Successfully rebased and updated refs/heads/feature/user-login.
(feature/user-login) $ 

🚨 실무 Rebase의 황금률 (The Golden Rule)

"이미 원격(GitHub/GitLab)에 공개되고 팀원들이 공유하고 있는 공용 브랜치(develop, main)에서는 절대 Rebase를 하지 마라!"

공용 브랜치를 Rebase하면 커밋 해시가 새로 바뀌어 다른 팀원들의 로컬 저장소와 심각한 충돌이 발생합니다. Rebase는 오직 "나 혼자 작업하는 개인 feature 브랜치"에서만 사용하세요.

Related Docs

Comments (0)

No comments yet. Be the first to comment!

Leave a Comment

로그인 후 댓글을 남길 수 있습니다.