Rebase: 무엇인지, rebase 작동 방식 및 Git 작업

Git에서 Rebase란

Rebase는 현재 브랜치를 지정된 브랜치로 리베이스하는 Git 명령어입니다. 현재 브랜치의 모든 커밋을 가져와 임시 저장하고, 브랜치 포인터를 대상 커밋으로 이동한 후 저장된 커밋을 순차적으로 그 위에 적용합니다. 결과적으로 개발자가 대상 브랜치의 최신 커밋에서 직접 작업한 것처럼 기록이 보입니다.

기본 구문: git rebase main — 피처 브랜치에 있는 상태에서 이 명령어는 모든 피처 커밋을 main의 끝으로 이동합니다. Git은 각 커밋마다 개별적으로 삼방향 병합 전략을 사용합니다. 커밋 A가 대상 브랜치에 이미 존재하는 경우(해시로 판단), Git은 자동으로 이를 건너뛰어 중복 변경을 방지합니다.

Rebase는 커밋의 하위 집합을 이동하기 위한 onto 모드도 지원합니다: git rebase --onto target start end — 이 형식은 한 브랜치에서 커밋 범위를 추출하여 다른 브랜치 위에 적용할 수 있습니다. 예를 들어, git rebase --onto main feature~3 feature는 피처 브랜치의 마지막 세 커밋을 main 위로 이동합니다.

# Switch to feature branch
git checkout feature

# Rebase feature onto main
git rebase main

# After successful rebase — history is linear
git log --oneline --graph

# Move last 3 commits to main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: 주요 차이점

Rebase와 merge는 동일한 작업(다른 브랜치의 변경 사항 결합)을 해결하지만 근본적으로 다른 방식으로 수행합니다. Merge는 두 부모가 있는 merge 커밋을 생성하여 전체 병합 기록을 보존합니다. Rebase는 기록을 다시 써서 선형으로 만듭니다. 둘 중 선택은 팀의 워크플로와 저장소 관리 규칙에 따라 달라집니다.

주요 차이점은 병합 사실이 기록되는 방식입니다. Merge는 “이 지점에서 피처를 main에 병합했습니다”를 보존합니다 — 이는 프로젝트 기록에 유용하지만 빈번한 병합으로 로그가 복잡해집니다. Rebase는 “피처 커밋이 main의 최신 상태에서 순차적으로 생성되었습니다”를 보여줍니다 — 깔끔하지만 개발이 병렬로 수행되었다는 사실을 숨깁니다.

두 번째 차이점은 충돌 처리입니다. Merge의 경우 충돌이 한 번 해결되고 해결 방법이 merge 커밋에 기록됩니다. Rebase의 경우 이동된 각 커밋에 대해 충돌이 발생할 수 있으며 각각 별도의 해결이 필요합니다. 더 많은 작업이 필요하지만 최종 버전에 어떤 변경 사항이 포함될지 더 정밀하게 제어할 수 있습니다.

대화형 Rebase: 명령어 및 플래그

대화형 rebase(git rebase -i)는 Git이 커밋 목록과 각 커밋에 사용 가능한 작업을 포함한 편집기를 여는 모드입니다. 개발자는 원격 저장소로 푸시하기 전에 기록을 다시 쓸 수 있습니다. 이는 피처 브랜치에서 깔끔한 커밋을 유지하기 위한 기본 도구입니다.

대화형 모드에서 사용 가능한 명령어: pick(커밋을 그대로 유지), reword(커밋 메시지 변경), edit(변경을 위해 중지), squash(이전 커밋과 결합, 두 메시지 유지), fixup(결합, 메시지 폐기), drop(커밋 삭제). 각 명령어는 열린 편집기에서 커밋 해시 앞에 배치됩니다.

Squash와 fixup은 커밋을 결합하는 데 가장 자주 사용되는 명령어입니다. 개발자가 작업 중 5개의 작은 수정 커밋을 만든 경우, squash는 이를 의미 있는 메시지가 있는 하나의 논리적 커밋으로 병합합니다. Fixup은 오타 수정에 유용합니다. 변경 사항이 자체 메시지를 유지하지 않고 이전 커밋에 포함됩니다.

# Open editor for last 4 commits
git rebase -i HEAD~4

# Editor will show:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# After saving — Git performs rebase
# and opens editor for squashed commit message

# Auto-squash without opening editor
git rebase -i HEAD~4 --autosquash

--autosquash 플래그는 fixup! 또는 squash!로 시작하는 메시지가 있는 커밋에 대해 자동으로 fixup/squash를 정렬합니다. 개발자가 나중에 결합하기 위해 미리 커밋에 표시하는 경우 작업 속도가 빨라집니다. --committer-date-is-author-date 플래그는 리베이스 시 원래 커밋 날짜를 보존합니다 — 기록의 시간순서 유지에 유용합니다.

Rebase 중 충돌 해결

Rebase 중 충돌은 대상 브랜치의 변경 사항과의 모순으로 인해 Git이 이동된 커밋을 자동으로 적용할 수 없을 때 발생합니다. Merge에서는 충돌이 한 번 해결되는 것과 달리, rebase에서는 각 커밋이 충돌을 일으킬 수 있으며 가장 오래된 것부터 가장 최근 것까지 순차적으로 해결해야 합니다.

충돌이 발생하면 Git이 rebase를 일시 중지하고 어떤 커밋이 문제를 일으켰는지 보고합니다. 개발자는 충돌하는 파일을 열고(Git은 충돌 영역을 <<<<<<<, =======, >>>>>>> 마커로 표시), 편집하고, 인덱스에 추가한 후(git add), git rebase --continue로 rebase를 계속합니다. 해결 방법을 찾을 수 없는 경우 — git rebase --abort가 rebase를 완전히 취소합니다.

팁: 여러 충돌이 있는 경우 충돌 해결을 위한 시각적 편집기를 여는 git mergetool을 사용하는 것이 더 효율적입니다. 문제가 있는 커밋을 건너뛸 수도 있지만(git rebase --skip), 최종 기록에서 변경 사항이 제거되므로 올바른 결정인 경우는 드뭅니다.

# Start rebase with conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

# Check status
git status
# both modified: file.txt

# Edit conflicted sections → git add → continue
git add file.txt
git rebase --continue

# If uncertain — abort
git rebase --abort

Rebase를 하면 안 되는 경우

Rebase의 황금률: 이미 원격 저장소에 푸시되어 다른 개발자가 사용할 수 있는 커밋은 절대 리베이스하지 마십시오. Rebase는 커밋 해시를 다시 쓰므로 동기화를 시도할 때 동료들이 충돌을 겪게 됩니다 — 로컬 기록이 다시 쓰여진 원격 기록과 달라집니다.

Rebase가 완전히 금지된 상황: 누군가 이미 귀하의 커밋을 기반으로 브랜치를 만든 경우(예: 동료가 귀하의 피처에서 브랜치를 만든 경우), 기록을 다시 쓰면 그들의 작업이 손상됩니다. 이러한 경우 merge를 사용하십시오. 또한 마감 직전에 rebase하는 것은 권장되지 않습니다 — 충돌 해결 오류가 예상보다 오래 걸려 릴리스를 차단할 수 있습니다.

예외: 브랜치를 한 명의 개발자만 사용하는 경우(개인 피처 브랜치, 게시되지 않았거나 초안 모드로 게시됨), 푸시 전 rebase는 표준 관행입니다. 게시 후 협업 작업 시작 시 — merge만 사용합니다. GitHub와 GitLab은 기본적으로 절충안으로 squash merge를 제공합니다: 커밋을 하나로 결합하지만 대상 브랜치의 기록은 다시 쓰지 않습니다.

• 공개 브랜치(main, develop, release) — rebase가 완전히 금지됩니다.
• 타인의 커밋 — 브랜치에 다른 개발자의 커밋이 포함된 경우 rebase가 허용되지 않습니다.
• 릴리스 전 — 충돌 위험이 더 높음: 마감 하루 전에는 merge가 더 안전합니다.
• 태그가 있는 브랜치 — 태그가 있는 커밋을 이동하면 시맨틱 버전 관리 규칙을 위반합니다.
• CI/CD가 해시에 연결됨 — 일부 배포 시스템은 커밋 해시로 빌드를 식별합니다. rebase는 추적을 손상시킵니다.

Rebase를 사용한 실용적 워크플로

현대 팀은 GitHub Flow와 결합된 rebase 중심 워크플로를 가장 자주 사용합니다. 프로세스는 다음과 같습니다: 개발자가 main에서 피처 브랜치를 만들고, 작업하며, 정기적으로 git rebase main을 통해 동기화하고, 풀 리퀘스트를 생성하기 전에 기록 정리를 위해 대화형 rebase를 수행합니다.

PR 생성 후(main에서 새 변경 사항을 가져와야 하는 경우), 일반 git pull 대신 git pull --rebase main이 사용됩니다. 이렇게 하면 불필요한 merge 커밋 없이 변경 사항을 가져옵니다. --rebase 플래그가 있는 git pull은 git fetch + git rebase와 동일합니다 — Git이 먼저 새 커밋을 다운로드한 다음 로컬 변경 사항을 그 위에 리베이스합니다.

Git은 pull의 기본 동작으로 rebase를 구성할 수 있습니다: git config --global pull.rebase true. 이 설정 후 git pull은 항상 merge 대신 rebase를 수행합니다. 일반 pull이 필요한 경우 — git pull --no-rebase를 사용합니다. 많은 팀이 autostash도 활성화합니다: git config --global rebase.autoStash true — 이렇게 하면 rebase 전에 커밋되지 않은 변경 사항이 자동으로 숨겨졌다가 이후 복원됩니다.