Git rebase vs merge 차이 — 언제 리베이스하고 언제 머지할까

브랜치를 합칠 때 git merge를 쓸지 git rebase를 쓸지는, 몇 년을 일한 개발자도 또 검색하게 되는 질문이다. 둘 다 "두 갈래로 나뉜 작업을 하나로 모은다"는 목적은 같은데, 히스토리를 다루는 철학이 정반대라서 그렇다. 한쪽은 있었던 일을 그대로 기록하고, 다른 한쪽은 없었던 것처럼 깔끔하게 다시 쓴다.

재밌는 건, "rebase는 위험하다더라" "우리 팀은 무조건 merge 금지" 같은 말을 신념처럼 외우면서도, 정작 커밋 그래프가 실제로 어떻게 달라지는지는 안 본 사람이 많다는 점이다. 그 그래프 한 장만 머리에 넣으면 막연한 공포도, 맹목적 신봉도 둘 다 사라진다.

같은 목표, 정반대 방식

상황을 하나 두자. main에서 갈라진 feature 브랜치에 커밋 두 개(C, D)를 쌓는 동안, 동료가 main에 E를 올렸다. 지금 내 저장소는 이렇게 갈라져 있다.

      A---B---E        main
           \
            C---D       feature

이 상태에서 merge를 하면 이렇게 된다.

      A---B---E----M    main
           \       /
            C---D--      feature

merge는 M이라는 합류 지점(머지 커밋)을 새로 하나 만든다. C, D, E의 원래 커밋 해시는 전부 그대로다. "언제 feature를 땄고, 그동안 main이 이만큼 갔고, 언제 둘을 합쳤다"는 사실이 그래프에 고스란히 남는다.

같은 상황에서 rebase는 전혀 다르게 움직인다.

      A---B---E            main
               \
                C'---D'     feature

rebase는 C, D를 통째로 들어내서 E 위에 다시 붙인다. 내용은 같지만 부모 커밋이 바뀌었으니 C', D'는 해시가 다른 새 커밋이다. 갈라졌던 흔적은 사라지고, 마치 처음부터 E 다음에 작업한 것처럼 일직선이 된다.

핵심은 이 한 줄이다. merge는 과거를 보존하고, rebase는 과거를 고쳐 쓴다. "커밋 해시가 바뀐다"가 rebase의 모든 장점과 위험을 동시에 설명한다.

표로 보는 차이

말로 풀면 헷갈리니 한 장에 놓고 보자.

표의 마지막 두 줄이 사실상 결론이다. 깔끔함을 얻는 대가로 추적성과 안전성을 내주는 게 rebase고, 그 반대가 merge다.

언제 rebase, 언제 merge

"그래서 뭘 쓰라는 거냐"에 대한 답은 생각보다 단순하다. 이 커밋을 나 혼자 보느냐, 남과 공유했느냐로 거의 갈린다.

• 내 로컬 feature 브랜치를 최신 main 위로 끌어올려 정리하고 싶다 → rebase (git pull --rebase 포함)
• PR 올리기 전, 지저분한 커밋 10개를 의미 단위 3개로 묶고 싶다 → rebase -i (squash)
• 여러 명이 같이 쓰는 브랜치나 release 브랜치를 본류에 합친다 → merge
• "이 기능이 언제 어느 릴리스에 들어갔나"라는 기록 자체가 중요하다 → merge (--no-ff로 머지 커밋을 일부러 남기기도)

실전에서 자주 쓰는 명령 몇 개

로컬을 최신으로 당길 때 — git pull --rebase

git pull --rebase
# 매번 치기 귀찮으면 아예 기본값으로
git config --global pull.rebase true

그냥 git pull은 내부적으로 fetch + merge라, 당겨올 때마다 Merge branch 'main' of ... 같은 공허한 머지 커밋이 하나씩 붙는다. 한 저장소를 오래 쓴 사람의 로그가 이런 머지 커밋으로 도배되는 이유가 이것이다. --rebase를 붙이면 내 로컬 커밋을 원격 최신 위에 다시 얹어 히스토리가 깔끔하게 유지된다.

커밋을 다듬을 때 — rebase -i

git rebase -i HEAD~5

최근 5개 커밋을 펼쳐 놓고 pick / squash / fixup / reword로 합치고 다듬는다. "오타 수정", "오타 또 수정", "진짜 마지막" 같은 커밋을 앞 커밋에 fixup으로 흡수시키면, 리뷰어가 볼 히스토리가 비로소 사람이 읽을 만해진다. 리뷰어 입장에서 커밋 메시지는 변경의 "목차"다. 목차가 엉망이면 리뷰 품질도 같이 떨어진다.

충돌이 났을 때

merge 충돌은 한 번 해결하면 끝난다. rebase는 커밋을 하나씩 다시 얹으므로 각 커밋 단계마다 충돌이 날 수 있다. 하나 해결하고 git rebase --continue, 도저히 안 되면 git rebase --abort로 손대기 전 상태로 완전히 되돌린다. 같은 충돌을 반복해서 푸는 게 지겨우면 이 설정을 켜 두면 좋다.

git config --global rerere.enabled true

여러 브랜치를 쌓아 올렸을 때 — update-refs

git rebase --update-refs

2022년 Git 2.38부터 들어온 옵션이다. 브랜치를 여러 개 쌓아 올린(stacked) 상태에서 맨 위를 rebase하면, 중간에 걸쳐 있던 브랜치 포인터들까지 알아서 따라 옮겨 준다. 스택 브랜치로 작업해 본 사람이면 이게 얼마나 손이 덜 가는 변화인지 안다.

진짜 중요한 단 하나의 금기

rebase에 관한 수많은 경고를 딱 한 줄로 줄이면 이거다. 이미 push해서 남과 공유한 커밋은 절대 rebase하지 않는다.

이유는 앞에서 이미 다 나왔다. rebase는 커밋을 새로 만들고(해시가 바뀐다), 동료는 옛 해시를 기준으로 자기 작업을 쌓고 있다. 그런데 내가 히스토리를 갈아끼운 뒤 그걸 force push로 밀어 버리면, 두 사람의 역사가 어긋난다. 동료의 커밋이 사라지거나, 다음 pull에서 같은 변경이 중복돼 충돌 지옥이 열린다.

그래서 규칙은 이렇게 단순해진다. rebase는 아직 나만 가진 로컬 커밋에만. main, develop, 남들이 pull하는 release처럼 공유된 브랜치는 merge로만 합친다.

국내 팀 현실에서 이 규칙이 자주 흔들리는 지점이 있다. 흔한 건 "PR 리뷰 도중에 main이 바뀌었으니 rebase해서 다시 올려"다. 이건 대개 안전하다 — 그 feature 브랜치는 보통 나 혼자 쓰니까. 진짜 사고는 둘 이상이 같은 feature 브랜치를 공유할 때 난다. 많은 한국 스타트업이 이 논쟁을 "PR은 Squash merge, 로컬은 rebase로 pull"이라는 팀 규칙 한 줄로 끝내 버린다. 개인 브랜치는 각자 rebase로 깔끔하게 관리하고, 합칠 때 어차피 커밋이 하나로 뭉쳐지니 "누가 옳냐" 논쟁 자체가 대부분 증발하기 때문이다.

반대로 git 교육이 부족한 팀에서는, 신입이 공유 브랜치에 git push --force를 날려 동료의 하루치를 지워 버리는 사고가 지금도 흔하게 난다. 그러니 정확히 말하면 rebase가 위험한 게 아니라, 공유 브랜치에 force push를 쓰는 게 위험한 거다. 이때 --force가 아니라 --force-with-lease를 습관처럼 쓰면 이런 사고의 상당수를 막을 수 있는데, 의외로 이 옵션을 아는 사람이 많지 않다. 팀에 git 규칙을 새로 깐다면 나는 이 한 줄부터 넣겠다.

정리하면

merge냐 rebase냐는 취향 싸움이 아니다. "이 커밋을 나 혼자 보느냐, 남과 공유했느냐"로 거의 결정된다. 혼자면 rebase로 깔끔하게, 공유했으면 merge로 안전하게. 그리고 공유 브랜치에 force push는 금지. 이 세 줄만 팀 위키 맨 위에 붙여 둬도 git 관련 사고의 대부분이 사라진다.

당신 팀은 어느 쪽인가? "무조건 rebase, 히스토리는 선형이어야 아름답다" 파인지, "머지 커밋도 엄연한 역사의 일부" 파인지 궁금하다. 둘을 섞어 쓴다면 어떤 기준으로 나누는지도.