Git 브랜치 전략, rebase와 merge 중 무엇을 쓸까

Git 브랜치 전략을 정하는 회의는 대개 rebase와 merge 중 무엇이 옳은지로 흘러간다. 그런데 이 논쟁에는 정답이 없고, 팀마다 다른 답이 맞는다. 이 글은 둘이 실제로 무엇을 다르게 하는지 짚고, 어떤 상황에서 어느 쪽을 골라야 하는지를 기준으로 정리한다. 그리고 이 논쟁보다 중요한 것이 무엇인지도 이야기한다.

둘은 같은 문제를 다르게 푼다

merge와 rebase는 한 브랜치의 변경을 다른 브랜치로 통합한다는 같은 목적을 가진다. 방법이 다르다.

merge는 두 브랜치의 끝을 이어 붙이는 새 커밋(머지 커밋)을 만든다. 원래 커밋들은 그대로 남고, 히스토리에 갈라졌다 합쳐진 모양이 기록된다.

rebase는 내 커밋들을 떼어내서 대상 브랜치의 최신 커밋 위에 하나씩 다시 얹는다. 결과적으로 히스토리가 한 줄로 펴진다. 원래 커밋은 남지 않고 새 해시를 가진 커밋으로 바뀐다.

이 차이가 실무에서 갈리는 지점은 두 가지다. 히스토리를 사실 그대로 남길 것인가, 읽기 좋게 정리할 것인가. 그리고 이미 공유된 커밋을 바꿔도 되는가.

지켜야 할 규칙은 하나뿐이다

전략은 팀마다 달라도, 지키지 않으면 사고가 나는 규칙이 하나 있다.

이미 공유된(push된) 브랜치는 rebase하지 않는다.

rebase는 커밋 해시를 바꾼다. 다른 사람이 그 브랜치를 받아 작업 중이라면, 그 사람의 히스토리와 내 히스토리가 갈라진다. 그 상태에서 다시 합치려 하면 같은 변경이 두 번 들어가거나 충돌이 반복된다.

그래서 일반적인 권장은 rebase는 로컬에서, merge는 공유 브랜치에서다. 내 피처 브랜치를 최신 main 위로 올릴 때는 rebase가 좋고, 그 피처 브랜치를 main으로 합칠 때는 merge를 쓴다.

혼자 쓰는 브랜치를 push한 뒤 rebase해야 한다면 --force-with-lease를 쓴다. 그냥 --force와 달리, 원격이 내가 아는 상태와 다르면 거절한다. 다른 사람이 그 사이에 push했다면 덮어쓰지 않는다.

세 가지 병합 방식을 조합한다

깃허브나 깃랩의 PR 병합 버튼에는 보통 세 가지 선택지가 있다.

방식	결과	어울리는 경우
Merge commit	머지 커밋 생성, 개별 커밋 보존	큰 기능, 작업 과정을 남겨야 할 때
Squash and merge	브랜치의 커밋을 하나로 합쳐 추가	커밋이 지저분한 피처 브랜치
Rebase and merge	커밋을 그대로 펴서 추가	커밋이 이미 잘 정리된 경우

실무에서 가장 많이 쓰이는 조합은 피처 브랜치는 squash, 릴리스 브랜치는 merge commit이다. 개발 중 "오타 수정", "다시 시도", "로그 제거" 같은 커밋이 쌓이는데, 이걸 그대로 main에 넣으면 히스토리가 쓸모없어진다. squash하면 main에는 기능 단위로 커밋 하나가 남는다.

squash의 단점도 알아야 한다. 커밋이 하나로 뭉개지므로 git bisect로 문제를 좁힐 때 해상도가 떨어진다. 커밋 하나가 파일 서른 개를 건드리면 그 안에서 다시 찾아야 한다. 그래서 PR을 작게 유지하는 것이 squash 전략의 전제 조건이다.

브랜치를 오래 살려두는 것이 진짜 문제다

여기서 내 관점을 분명히 하고 싶다. rebase냐 merge냐보다 훨씬 중요한 것은 브랜치가 얼마나 오래 사는가다.

브랜치가 2주를 넘어가면 무슨 전략을 써도 고통스럽다. main이 그동안 많이 바뀌었으므로 충돌이 대량으로 나고, 충돌을 해결하는 과정에서 실수가 들어간다. rebase로 펴든 merge로 합치든 그 고통은 비슷하다.

반대로 브랜치가 하루나 이틀이면 충돌 자체가 거의 없다. 그러면 어떤 전략을 쓰든 문제가 되지 않는다. 전략 논쟁이 격렬한 팀은 대개 브랜치가 오래 사는 팀이다.

그래서 트렁크 기반 개발(trunk-based development)이 주목받는다. 요지는 단순하다. 모두가 main에 자주 병합하고, 긴 브랜치를 만들지 않는다. 아직 완성되지 않은 기능은 피처 플래그로 감춰서 배포한다.

이 방식의 전제는 자동화된 테스트와 빠른 CI다. 하루에 여러 번 main에 병합하려면 병합해도 안전하다는 확신이 있어야 한다. 테스트가 없거나 CI가 30분씩 걸리는 팀이 트렁크 기반을 도입하면 main이 자주 깨진다.

그래서 어떻게 정할 것인가

팀 상황에 따라 이렇게 고른다.

팀이 작고 CI가 빠르다면 트렁크 기반에 가깝게 가고, 병합은 squash로 통일한다. 규칙이 단순해서 설명할 것이 적다.

릴리스 주기가 정해져 있고 여러 버전을 동시에 관리한다면 Git Flow 계열이 여전히 유효하다. 릴리스 브랜치와 핫픽스 브랜치가 실제로 필요한 상황이 있다.

오픈소스처럼 기여자가 흩어져 있다면 개별 커밋을 보존하는 편이 낫다. 누가 무엇을 기여했는지가 히스토리에 남아야 한다.

어느 쪽이든 팀 안에서 하나로 통일하는 것이 개별 선택보다 중요하다. 사람마다 다르게 하면 히스토리가 뒤죽박죽이 되고, 그때부터는 어떤 전략의 장점도 얻지 못한다. 문서에 한 페이지로 적어두고 PR 템플릿에 넣어두면 대체로 지켜진다.

마지막으로 하나. 히스토리를 아름답게 만드는 것 자체는 목적이 아니다. 히스토리가 필요한 이유는 나중에 "이 코드가 왜 이렇게 됐는지" 알기 위해서다. 그 목적에 도움이 되는 만큼만 정리하면 된다. 커밋 메시지에 이유를 쓰지 않으면서 히스토리 모양만 다듬는 것은 앞뒤가 바뀐 일이다.

충돌을 덜 만드는 습관

전략과 별개로, 충돌 자체를 줄이는 습관이 있다. 이게 효과가 가장 크다.

main 을 자주 받아온다. 하루에 한 번은 git pull --rebase origin main으로 내 브랜치를 최신 위로 올린다. 매일 조금씩 충돌을 해결하는 것이, 2주 뒤에 한꺼번에 해결하는 것보다 훨씬 쉽다.

같은 파일을 여러 사람이 동시에 고치지 않도록 작업을 나눈다. 이건 기술이 아니라 계획의 문제다. 스탠드업에서 "오늘 나는 결제 모듈을 만진다"고 공유하는 것만으로도 충돌이 줄어든다.

포매터를 통일한다. 들여쓰기나 줄바꿈 규칙이 사람마다 다르면, 같은 줄을 서로 다르게 포맷해서 충돌이 난다. 내용은 같은데 충돌만 나는 상황이 제일 허무하다. .editorconfig와 포매터 설정을 저장소에 넣어두면 사라지는 문제다.

대규모 포매팅 변경은 별도 커밋으로 분리한다. 파일 전체를 다시 포맷하는 커밋은 다른 모든 브랜치와 충돌한다. 이런 작업은 날을 잡아서 하고, .git-blame-ignore-revs 파일에 그 커밋 해시를 등록해 두면 git blame에서 무시된다.

참고 자료

• Merging vs. Rebasing — Atlassian Git Tutorial — 두 방식의 동작 차이와 황금률
• Git - Rebase 하기 (Pro Git 한국어판) — rebase 의 원리와 주의사항
• Git의 다양한 브랜치 병합 방법 (Merge, Squash & Merge, Rebase & Merge) — 세 가지 병합 방식의 결과 비교
• Git 브랜치 전략 수립을 위한 전문가의 조언들 — 화해 기술블로그 — 팀 상황에 맞춘 전략 선택 사례