Rebase: 개념, Merge와의 차이점 및 작동 원리

Rebase란 무엇인가?

Rebase(리베이스)는 현재 브랜치에서 새 베이스 포인트로 커밋을 이동시키는 Git 작업입니다. 병합 커밋을 생성하는 대신, rebase는 소스 브랜치의 각 커밋을 가져와 새 베이스 위에 하나씩 적용합니다. 결과는 분기가 없는 선형 커밋 시퀀스입니다.

Rebase라는 이름은 “re-base”(베이스 변경)에서 유래했습니다. merge가 두 브랜치를 한 지점에서 결합하는 반면, rebase는 브랜치 전체를 새 위치로 효과적으로 이동시켜 대상 브랜치의 현재 상태에서 개발을 시작한 것처럼 보이게 합니다. 이는 완벽하게 순차적인 작업의 환상을 만듭니다.

Atlassian, 2025에 따르면, 피처 브랜치에 rebase를 사용하는 팀은 merge만 사용하는 팀에 비해 커밋 기록 분석에 30% 적은 시간을 소비합니다. 선형 기록은 git blame, bisect 및 git log --oneline을 통한 로그 보기를 단순화합니다.

Merge와의 근본적인 차이점

Merge는 두 개의 부모를 가진 커밋을 생성하여 브랜치를 결합합니다. Rebase는 기록을 다시 씁니다. 변경 내용은 원본과 동일하지만 새 해시로 새 커밋이 생성됩니다. 즉, rebase는 커밋의 SHA 식별자를 변경하며, 이는 공개 브랜치에 중요합니다.

Rebase의 작동 방식

Rebase 메커니즘은 네 단계로 구성됩니다. Git은 현재 브랜치와 대상 브랜치의 공통 조상(병합 베이스)을 확인한 다음, 현재 브랜치의 각 커밋을 대상 브랜치 위에 순차적으로 적용합니다. 단계에서 충돌이 발생하면 rebase가 중지되고 해결을 기다립니다.

# 초기 상황: feature 브랜치가 develop보다 3커밋 뒤처짐
git checkout feature/new-login
git rebase develop

# Git이 feature에서 3개의 커밋을 가져와 develop 위에 적용
# 충돌이 없으면 — rebase가 자동으로 완료됨
# 충돌이 있으면 — Git이 충돌하는 커밋에서 중지

Rebase 후 피처 브랜치에는 develop의 모든 커밋과 develop의 연속으로 표시되는 자체 커밋이 포함됩니다. 이를 통해 병합 커밋을 생성하지 않고 fast-forward로 develop에 병합할 수 있습니다.

단계별 프로세스

자세한 예를 살펴보겠습니다. 개발자가 develop에서 피처 브랜치를 만들고 두 개의 커밋을 했으며, 그 사이에 다른 개발자가 develop에 세 개의 커밋을 추가했습니다. Rebase는 두 피처 커밋을 새 위치로 이동하고 새 SHA로 복사본을 만듭니다.

# 1. feature 브랜치 생성
git checkout -b feature/payment-refactor develop

# 2. feature에서 커밋 수행
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. develop 업데이트(동료 작업)
git checkout develop
git pull

# 4. 새 develop 위에 feature 리베이스
git checkout feature/payment-refactor
git rebase develop

# 5. 이제 fast-forward를 통해 feature 병합 가능
git checkout develop
git merge feature/payment-refactor

4단계에서 충돌이 발생하면 Git이 문제의 커밋에서 중지됩니다. 개발자가 충돌을 해결하고 git add를 실행한 다음 git rebase --continue를 실행합니다. 커밋을 건너뛰려면 — git rebase --skip, 전체 rebase를 취소하려면 — git rebase --abort입니다.

빈 커밋 자동 건너뛰기

--empty 플래그는 빈 커밋(커밋의 모든 변경 사항이 이미 대상 브랜치에 있는 상황)에 대한 rebase 동작을 제어합니다. 기본적으로 rebase는 중지되고 결정을 요청합니다. --empty=drop을 사용하면 Git이 중지하지 않고 자동으로 해당 커밋을 건너뛰어 많은 수의 커밋이 포함된 대량 리베이스를 가속화합니다.

대화형 Rebase

대화형 rebase(git rebase -i)는 커밋 기록을 편집하기 위한 강력한 도구입니다. 커밋 목록과 키 명령어(pick(유지), reword(메시지 변경), edit(내용 변경), squash(이전과 병합), fixup(메시지 없이 병합), drop(삭제))가 포함된 편집기가 열립니다.

# 마지막 4개 커밋의 대화형 rebase
git rebase -i HEAD~4

# 편집기에 rebase 계획이 열립니다:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# 다음으로 변경:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

결과: 세 개의 커밋(로그인 화면, 유효성 검사, 레이아웃)이 하나로 압축되고 주석이 있는 커밋은 삭제됩니다. 이를 통해 초안 및 수정 사항 없이 코드 검토를 위해 깔끔한 기록을 제출할 수 있습니다. 대화형 rebase는 Pull Request 전에 피처 브랜치를 준비하는 표준 도구입니다.

Rebase vs Merge: 비교

Rebase와 Merge는 동일한 문제(변경 사항 통합)를 해결하지만 근본적으로 다른 방식으로 해결합니다. 둘 중 선택은 git log에서 어떤 종류의 기록을 보고 싶은지와 누가 브랜치에서 작업하는지에 따라 달라집니다.

실용적인 규칙: 공유 브랜치(develop, main)로의 통합에는 merge를 사용하고 개인 피처 브랜치 업데이트에는 rebase를 사용하세요. 많은 팀이 둘을 결합합니다. develop에 피처를 rebase한 다음 develop에 --no-ff merge를 수행합니다.

git bisect에 미치는 영향

Git bisect는 회귀를 도입한 커밋을 찾기 위한 도구입니다. merge를 사용할 때 git bisect는 두 부모를 모두 고려하여 병합 커밋을 올바르게 통과합니다. Rebase를 사용하면 기록이 선형이고 분기가 필요하지 않아 bisect가 더 빠르게 작동합니다. 그러나 커밋이 팀에 알려진 후에 rebase가 수행된 경우 원래 SHA가 손실되어 bisect가 문제의 커밋을 찾지 못할 수 있습니다.

Rebase 사용 시기

Rebase는 세 가지 시나리오에서 최적입니다. Pull Request를 위한 피처 브랜치 준비, main/develop의 현재 상태로 개인 브랜치 업데이트, 병합 전 기록 정리입니다. 각 경우에 rebase는 팀 작업에 위험을 주지 않으면서 기록 가독성을 향상시킵니다.

Pull Request 전에 초안 커밋(WIP, 검토 후 수정)을 의미 있는 논리 단위로 결합하기 위해 대화형 rebase를 수행하는 것이 좋습니다. 이렇게 하면 코드 검토가 쉬워집니다. 검토자는 15개의 작은 커밋이 아니라 명확한 메시지가 있는 3-5개의 구조화된 변경 사항을 봅니다.

피처 브랜치 업데이트의 경우 rebase가 merge보다 선호됩니다. 불필요한 병합 커밋을 만들지 않기 때문입니다. 피처 브랜치 내에서 정기적으로 git rebase develop을 실행하면 최종 병합 시 10개의 병합 커밋이 계단식으로 쌓이지 않고 develop 위에 깔끔한 피처 커밋만 남습니다.

병합 전 대화형 rebase를 통한 기록 정리는 사소한 수정(오타, 서식)을 숨기고 기능별로 커밋을 그룹화할 수 있게 합니다. Git 메시지는 Conventional Commits 규칙(fix:, feat:, refactor:, docs:)을 따라야 하며, 이는 자동 변경 로그를 생성합니다.

Rebase의 위험 및 규칙

Rebase는 잘못 적용하면 위험한 작업입니다. 주요 위험은 게시된 기록을 다시 쓰는 것입니다. 개발자가 다른 사람이 이미 푸시하여 사용 중인 브랜치를 rebase하면 로컬 복사본이 동기화되지 않아 데이터 손실 위험과 함께 force-pull을 수행해야 합니다.

• 황금 규칙: 공유 저장소에 이미 존재하는 커밋은 절대 rebase하지 마세요. 이는 팀의 다른 구성원이 접근할 수 있는 모든 브랜치에 적용됩니다
• Force push: 로컬 피처 브랜치를 rebase한 후에는 --force-with-lease 플래그로 푸시해야 합니다. 서버에서 누군가 브랜치를 업데이트했는지 확인하므로 --force보다 안전합니다
• 컨텍스트 손실: rebase는 피처 브랜치가 언제, 어떤 브랜치에서 생성되었는지에 대한 정보를 삭제합니다. 브랜치 생성 날짜를 보존하는 것이 중요하다면 merge를 사용하세요
• 충돌: rebase 중에는 각 커밋에 대해 개별적으로 충돌을 해결해야 하며, 커밋 수가 많으면 지루할 수 있습니다

위험을 최소화하려면 다음 규칙을 따르세요. 게시되지 않은 개인 브랜치에만 rebase를 사용하세요. 브랜치가 이미 공유 저장소에 있는 경우 --no-ff와 함께 merge를 사용하세요. 게시된 브랜치를 rebase해야 하는 경우 팀에 미리 경고하고 force push를 조정하세요.

위험한 rebase에 대한 자동 보호는 서버 측 훅을 통해 구현됩니다. Git 서버의 pre-receive 훅은 푸시가 게시된 커밋을 다시 쓰는지 확인할 수 있습니다. GitHub 및 GitLab은 보호된 브랜치에 대한 내장 보호를 제공합니다 — 관리자가 보호를 해제하지 않으면 force push가 차단됩니다.