[Git] rebase vs merge, 언제 쓰는 게 좋을까?

rebase vs merge, 언제 쓰는 게 좋을까?

Git에서는 브랜치를 병합할 때 merge와 rebase 두 가지 전략을 사용할 수 있습니다.
이 두 방식은 모두 같은 목적(변경 내용을 하나로 합치기)을 가지지만, 기록 방식과 협업 시 주의점이 다릅니다.

---

 기본 개념 비교

구분mergerebase

목적	브랜치 병합	커밋을 다른 브랜치 위로 재적용
기록 구조	브랜치의 흐름 유지 (병합 커밋 생성)	선형 히스토리 정리 (브랜치 끼워넣기)
커밋 ID	그대로 유지	새로 생성됨
충돌 발생	한 번에	각 커밋마다

 간단 비유

• merge: 두 개의 나뭇가지를 한 데 묶는 것
• rebase: 나뭇가지의 내용을 주 줄기에 옮겨 심는 것

---

 명령어 예시

 merge 사용 예

git switch main
git merge feature/login

→ main 브랜치 위에 feature/login의 변경 내용을 합칩니다.

 rebase 사용 예

git switch feature/login
git rebase main

→ feature/login 브랜치의 시작점을 main 이후로 재배치하여 기록을 일직선으로 정리합니다.

---

 사용 시기 가이드

 merge가 적합한 경우

• 팀 협업 중인 메인 브랜치 병합
• 커밋 이력 보존이 중요한 경우
• 충돌 발생을 한 번에 처리하고 싶을 때

 rebase가 유리한 경우

• 개인 작업 브랜치에서 최신 main 브랜치 반영할 때
• 깔끔한 커밋 히스토리가 필요한 경우
• 커밋을 정리해 한 줄의 흐름을 만들고 싶을 때

---

 주의할 점

 rebase 주의사항

• 협업 중인 공유 브랜치에는 절대 rebase 금지!
• 커밋 ID가 변경되기 때문에 이미 공유된 브랜치에서 rebase하면 푸시 충돌이나 이력 꼬임 발생

 안전하게 쓰는 팁

• git pull --rebase는 내 로컬 작업을 최신화할 때 유용
• git rebase -i로 커밋 정리(pick, squash 등) 가능
• rebase 후에는 가급적 force-with-lease로 푸시

git push --force-with-lease

---

 git rebase -i 사용법 요약

커밋 여러 개를 정리하거나 병합(squash)할 때 유용한 인터랙티브 모드입니다.

git rebase -i HEAD~3  # 최근 3개 커밋 정리

 주요 명령어

키워드	설명
pick	해당 커밋 유지
reword	커밋 메시지만 수정
edit	해당 커밋에서 코드 직접 수정
squash	이전 커밋과 합치기 + 메시지 수정 가능
fixup	이전 커밋과 바로 합치기 (메시지 생략)

예를 들어, 3개의 커밋을 하나로 묶고 싶다면 아래처럼 설정:

pick a1b2c3 기능 1 구현
squash d4e5f6 기능 2 보완
squash g7h8i9 주석 추가

---

 실습 예제: 충돌 해결 비교

상황

• main 브랜치에서는 button.css에서 색상을 "blue"로 수정
• feature/ui-fix 브랜치에서는 같은 줄을 "green"으로 수정 후 병합 시도

 merge의 경우

git switch main
git merge feature/ui-fix

→ 충돌 발생 (한 번에 충돌 확인) → 충돌 해결 후 git add → git commit 하면 완료

 rebase의 경우

git switch feature/ui-fix
git rebase main

→ 첫 커밋부터 차례대로 재적용하면서 충돌 발생 → 커밋마다 충돌을 해결 후 git rebase --continue

 충돌 마크 예시 (VS Code 또는 CLI에서)

<<<<<<< HEAD
background-color: blue;
=======
background-color: green;
>>>>>>> feature/ui-fix

위처럼 Git은 충돌 지점을 <<<<<<<, =======, >>>>>>>으로 구분 표시해줍니다. 수정 후 반드시 git add → git commit 또는 git rebase --continue 필요

---

실전 협업 시 브랜치 전략 예시

협업 시 브랜치 전략을 잘 설정하면 merge/rebase 충돌을 줄이고 작업 흐름이 원활해집니다.

 일반적인 브랜치 구조

main           ← 운영 배포 기준 (절대 force-push 금지)
dev            ← 개발 통합 브랜치
feature/login  ← 기능 개발 단위 브랜치
bugfix/header  ← 버그 수정 단위 브랜치
hotfix/payment ← 긴급 수정용 브랜치

협업 팁

• main은 항상 최신 상태 유지, CI/CD 기준이 되도록
• feature/* 브랜치는 작업자 이름 + 기능명 조합 권장 (예: feature/jane-profile-ui)
• 모든 PR은 dev를 기준으로 보내고, main에는 테스트 후 병합

---

 정리 요약

항목	merge	rebase
기록 구조	브랜치가 갈라지고 병합됨	커밋이 재작성되어 일직선 흐름
충돌 발생	병합 지점에서 한 번	각 커밋마다 발생 가능
협업 적합	✅ 안정적	❌ 공유 브랜치에는 부적합
히스토리	복잡해질 수 있음	깔끔하게 정리 가능
커밋 정리	불편	✅ rebase -i로 유연하게 조정 가능