1. Git Rebase란?

rebase는 말 그대로 "기준(base)을 다시 설정한다" 는 뜻이다. 브랜치가 다른 브랜치로부터 분기된 시점, 즉 출발점을 새로운 커밋 위로 옮겨주는 작업이다.

비유하자면 이렇다. 회의실 예약을 A 시간대에 맞춰 발표 자료를 준비했는데, 회의가 B 시간대로 옮겨졌다. 발표 내용 자체는 그대로지만, 발표를 시작하는 기준 시간이 달라진 것이다. rebase도 마찬가지로 내가 작업한 커밋들의 내용은 그대로 두되, 그 커밋들이 시작되는 "베이스"만 최신 커밋으로 옮겨 붙이는 작업이다.

결과적으로 커밋 그래프가 직선에 가깝게 정리되어, merge보다 히스토리가 훨씬 깔끔하게 보인다.

2. Merge vs Rebase — 구조적 차이

2-1) Merge: 두 브랜치를 "만나게" 한다

git checkout feature
git merge main

    C---D---E---M  feature (M = merge commit)
   /           /
A---B-------F---G  main

merge는 두 브랜치의 변경 이력을 하나로 합치는 시점에 merge commit(M) 을 새로 만든다. 이 커밋은 feature의 커밋(C, D, E)과 main의 최신 커밋(F, G) 양쪽을 모두 부모로 갖는 특별한 커밋이다. 브랜치가 갈라졌다가 다시 합쳐지는 구조가 그래프에 그대로 남기 때문에, 작업 흐름을 시각적으로 파악하기엔 좋지만 히스토리가 복잡하게 꼬일 수 있다.

2-2) Rebase: 한 브랜치를 "옮겨" 합친다

git checkout feature
git rebase main

# rebase 전
      C---D---E  feature
     /
A---B---F---G  main

# rebase 후
              C'---D'---E'  feature
             /
A---B---F---G  main

rebase는 feature의 커밋들(C, D, E)을 main의 최신 커밋(G) 위에 하나씩 재생(replay) 한다. 기존 커밋을 그대로 이동시키는 게 아니라, 같은 변경사항을 담은 새로운 커밋(C', D', E') 을 다시 만들어 붙이는 것이다. 이 때문에 커밋 해시값이 바뀐다는 점을 반드시 기억해야 한다.

2-3) Merge와 Rebase 핵심 비교

구분 Merge Rebase
히스토리 형태 비선형 (다이아몬드 구조) 선형 (일직선)
Merge commit 생성됨 생성되지 않음
커밋 해시 유지됨 변경됨 (새 커밋 생성)
충돌 처리 한 번에 해결 커밋마다 순차적으로 해결
공개 브랜치 적용 안전함 위험할 수 있음
작업 이력 보존 브랜치 분기 이력까지 보존 이력을 깔끔하게 재작성

2-4) rebase 후 "완전한 일직선"이 되는 시점

rebase를 하고 push해도, Source Tree나 GitHub에서 보면 여전히 두 개의 브랜치로 나뉘어 보인다. 이는 정상적인 현상이다.

# rebase 후, PR merge 전
              C'---D'---E'  origin/feature
             /
A---B---F---G  origin/main