Rebase vs Merge

Rebase와 merge는 내용보다 모양과 의도가 달라

둘 다 한 branch의 작업을 다른 branch에 통합하지만 이력에 남기는 모양이 달라. Merge는 parent가 둘인 새 commit으로 두 이력을 Y자에서 합쳐서 두 흐름을 graph에 보존해. Rebase는 source branch의 commit을 target tip 위에 새 commit으로 replay해 merge commit 없는 직선 chain을 만들어. 최종 내용은 같을 수 있어도 이력의 의미는 크게 달라.

결정 기준은 발산이 의미 있는지야. 장기 release branch를 합치거나 기능 완성을 작업 단위로 표시하고, 어디서 왔는지 audit trail을 보존하려면 merge해. 내가 feature를 만드는 동안 main도 움직였다는 우연한 발산이라면 rebase해. 짧은 feature branch마다 main을 merge하면 이력에 잡음이 쌓여. 날마다 ship하는 제품 팀에서는 rebase한 feature branch가 main을 기능의 단일 sequence로 읽히게 해.

팀 정책은 셋 가운데 하나를 고를 수 있어. (a) 모든 PR을 main 위에 rebase하고 fast-forward merge해 직선 이력을 만들기, (b) fast-forward할 수 있어도 --no-ff merge commit을 만들어 feature 단위를 남기기, (c) PR의 commit을 merge 때 하나로 squash해 main을 단순하게 만들기야. 셋 다 일관되게 쓰면 말이 돼. 뒤섞는 것이 진짜 문제야.

feature branch에서 git rebase main을 실행하면 로컬 commit을 main의 현재 tip 위에 replay해. conflict가 나면 rebase가 멈추고 해결 뒤 git rebase --continue로 이어가. git rebase --onto <new-base> <old-base> <branch>는 branch의 base를 정밀하게 바꿔. 처음에 잘못된 곳에서 branch를 만들었을 때 유용해.

Code

두 통합 모양·bash

# Feature 를 현재 main 에 rebase:
git switch feature/x
git fetch origin
git rebase origin/main

# 결과: feature/x 의 commit 들이 origin/main 위에 선형으로 자리.

# Merge 대신:
git switch main
git merge feature/x          # 가능하면 FF, 아니면 three-way
git merge --no-ff feature/x  # 항상 merge commit 생성

Rebase --onto 로 정밀 re-parenting·bash

# feature/email-templates 를 feature/auth 에서 분기했는데
# feature/auth 가 폐기될 예정. email-templates 를 main 위에
# 살게 하고 싶다.

git rebase --onto main feature/auth feature/email-templates

# 해석: "feature/email-templates 의 feature/auth 이후 commit 을
# main 에 replay, 옛 base 교체."

Exercise

같은 baseline에서 시작하는 연습용 repo 둘을 만들어. 하나는 feature branch를 git merge --no-ff로 통합하고, 다른 하나는 git rebase main한 뒤 fast-forward merge해. 각각 git log --oneline --graph --all을 실행해 모양을 비교하고, 6개월 뒤 어느 쪽이 더 읽기 좋을지 한 줄로 이유를 적어.

Rebase와 merge는 내용보다 모양과 의도가 달라

Code

External links

Exercise

Progress

댓글 0