브랜치를 정리하려고 git rebase를 돌렸는데, 커밋 하나 넘어갈 때마다 충돌이 터지고 그 충돌 안에 또 여러 개의 충돌 블록이 섞여 있는 상황. 겪어본 분이라면 압니다. 이럴 때 가장 곤란한 건 문법을 몰라서가 아니라, "이 부분은 내 코드가 맞는 건가, 저 코드가 맞는 건가"를 판단하는 기준이 없다는 점입니다. 이번 글에서는 리베이스 중 다중 충돌이 왜 생기는지, 그리고 그중 무엇을 남길지 판단하는 실전 기준을 정리해봤습니다.
목차
1. 리베이스 중 충돌이 여러 개 겹치는 이유
2. "누구 것이 맞는지" 판단하는 다섯 가지 기준
3. 실전에서 충돌을 정리하는 순서
4. 마무리
#1. 리베이스 중 충돌이 여러 개 겹치는 이유
1) 리베이스는 커밋을 하나씩 다시 쌓는 작업이다
먼저 리베이스가 무엇을 하는 작업인지부터 짚고 가겠습니다. git rebase는 내 브랜치의 커밋들을 잠시 떼어냈다가, 기준이 되는 브랜치(보통 main이나 develop) 위에 커밋을 하나씩 다시 순서대로 적용하는 작업입니다. merge가 두 브랜치의 변경 이력을 한 번에 합치는 방식이라면, rebase는 "내가 만든 커밋들을 최신 기준 위에서 처음부터 다시 만든다"고 이해하면 쉽습니다.
문제는 이 과정이 커밋 단위로 순차 진행된다는 점입니다. 내 브랜치에 커밋이 10개 있다면, 그 10개를 하나씩 기준 브랜치 위에 재적용하면서 매 커밋마다 충돌 여부를 검사합니다. 그래서 merge 한 번으로 끝날 충돌이, rebase에서는 커밋 개수만큼 반복해서 발생할 수 있습니다.
· · · · ·
2) 왜 한 커밋 안에서도 충돌이 여러 개 뜨는 걸까
"커밋마다 충돌이 난다"는 것과 별개로, 커밋 하나를 적용하는 중에도 파일 여러 곳에서 동시에 충돌 표시(<<<<<<<, =======, >>>>>>>)가 뜨는 경우가 흔합니다. 이는 같은 파일의 여러 줄을 나와 다른 사람이 각각 다르게 수정했기 때문입니다. 예를 들어 함수 시그니처를 바꾼 부분과, 그 함수 내부 로직을 바꾼 부분이 서로 다른 사람의 커밋에 걸쳐 있다면, 하나의 rebase 스텝에서 여러 개의 충돌 블록이 동시에 나타나게 됩니다.
① 여러 사람이 같은 함수나 파일을 동시에 수정했을 때
② 리팩터링(코드 구조를 바꾸는 작업)과 기능 추가가 같은 파일에서 겹쳤을 때
③ 오래 묵힌 브랜치를 뒤늦게 rebase하면서 그 사이 변경 이력이 많이 쌓였을 때
#2. "누구 것이 맞는지" 판단하는 다섯 가지 기준
1) 기준 1 - 최신 의도를 반영한 쪽이 우선이다
가장 먼저 물어야 할 질문은 "둘 중 어느 쪽이 더 최근의 의도를 담고 있는가"입니다. rebase 충돌은 시간 순서가 명확하게 드러나는 상황이라, 커밋 로그(git log)를 통해 각 변경이 언제, 왜 이뤄졌는지 확인할 수 있습니다. 단순히 "먼저 쓴 사람이 맞다"가 아니라, 더 나중에 반영된 정책이나 요구사항을 담은 쪽이 우선이어야 하는 경우가 많습니다.
· · · · ·
2) 기준 2 - 테스트와 빌드가 통과하는 쪽이 맞다
코드 리뷰만으로 판단이 안 설 때는 실제로 동작하는 쪽을 기준으로 삼아야 합니다. 충돌을 해결한 뒤에는 반드시 테스트를 돌려봐야 하는데, 두 코드 중 하나를 선택하는 게 아니라 둘 다 살려야 하는 경우도 있다는 점을 염두에 둬야 합니다. 겉보기엔 "둘 중 하나를 고르는 문제"처럼 보여도, 실제로는 두 변경을 합쳐야 정상 동작하는 경우가 의외로 많습니다.
· · · · ·
3) 기준 3 - 해당 코드의 오너(주인)에게 물어보는 것을 부끄러워하지 않는다
git blame으로 그 줄을 마지막으로 수정한 사람을 확인할 수 있습니다. 애매하다면 직접 물어보는 것이 가장 빠르고 정확합니다. 혼자 판단해서 잘못된 코드를 남기는 것보다, 슬랙 메시지 한 줄로 30초 만에 확인하는 것이 훨씬 안전합니다. 특히 비즈니스 로직처럼 도메인 지식이 필요한 부분은 더더욱 그렇습니다.
· · · · ·
4) 기준 4 - PR/이슈 설명에 근거가 있는지 확인한다
각 커밋이 어떤 PR(Pull Request)이나 이슈에서 나온 것인지 확인하면, 왜 그렇게 수정했는지 맥락을 알 수 있습니다. 커밋 메시지만 보고 판단하기보다, 연결된 PR 설명이나 이슈 코멘트를 확인하면 단순 실수로 남은 코드인지, 의도된 변경인지 훨씬 명확해집니다.
· · · · ·
5) 기준 5 - 둘 다 맞다면, 병합이 정답이다
마지막으로 가장 흔하지만 놓치기 쉬운 기준입니다. 충돌이 났다고 해서 반드시 둘 중 하나를 선택해야 하는 것은 아닙니다. 두 변경이 서로 다른 목적으로 같은 부분을 건드린 경우, 두 코드를 모두 반영해서 합치는 것이 정답인 경우가 오히려 더 많습니다. "여기서 뭘 골라야 하지"라는 질문 자체를 "이 둘을 어떻게 합쳐야 하지"로 바꿔보는 것이 실전에서 훨씬 유용합니다.
#3. 실전에서 충돌을 정리하는 순서
1) 충돌 표시를 읽는 법부터 정확히 알기
충돌이 나면 파일에 아래와 같은 표시가 나타납니다.
<<<<<<< HEAD // 기준 브랜치(리베이스 대상)의 코드
======= // 내가 만든 커밋의 코드
>>>>>>> abc1234 (내 커밋 메시지)
여기서 헷갈리는 부분이 있는데, rebase 중에는 merge와 반대로 HEAD가 '기준 브랜치'를, 아래쪽이 '내가 새로 얹으려는 커밋'을 가리킵니다. 이 방향을 반대로 착각한 채 판단하면 엉뚱한 코드를 남기게 되니, 이 표시 순서를 정확히 기억해두는 것이 첫걸음입니다.
· · · · ·
2) 명령어로 실전 흐름 정리하기
충돌이 여러 파일, 여러 블록에 걸쳐 있을 때는 아래 순서로 진행하면 정신없이 헤매지 않을 수 있습니다.
# 1. 어떤 파일에서 충돌이 났는지 확인
git status
# 2. 파일별로 충돌 블록을 하나씩 확인하며 수정 # 3. 수정이 끝난 파일을 스테이징
git add [파일명]
# 4. 다음 커밋으로 계속 진행
git rebase --continue
# 도저히 판단이 안 서면 중단하고 원래 상태로
git rebase --abort
① 한 번에 모든 파일을 고치려 하지 말고, 파일 하나씩 끝내고 다음으로 넘어갑니다.
② git add를 하기 전, 반드시 눈으로 충돌 표시(<<<<<<<, =======, >>>>>>>)가 모두 제거됐는지 확인합니다.
③ 애매한 판단이 3개 이상 겹치면 무리하게 진행하지 말고 rebase --abort로 되돌린 뒤, 팀원과 상의 후 다시 시작하는 것이 시간을 아끼는 길입니다.
· · · · ·
3) 도구를 활용하면 실수를 줄일 수 있다
충돌 블록이 많을수록 눈으로만 판단하다 실수하기 쉽습니다. VS Code나 IntelliJ 같은 IDE의 3-way merge 도구를 사용하면 기준 브랜치, 내 브랜치, 공통 조상(base) 세 가지를 나란히 비교하며 판단할 수 있어 훨씬 안전합니다. `git mergetool` 명령으로 설정된 외부 병합 도구를 바로 실행할 수도 있습니다.
4. 마무리
rebase 중 다중 충돌은 결국 "누가 맞았나"를 가리는 문제가 아니라 "무엇이 지금 시점에 맞는 코드인가"를 가리는 문제였습니다. 최신 의도, 실제 동작 여부, 코드 오너의 확인, PR 맥락이라는 네 가지 기준으로 우선 판단하고, 그래도 애매하다면 둘 다 살려서 합치는 다섯 번째 기준을 떠올리면 대부분의 상황을 정리할 수 있습니다.
충돌 표시의 방향(HEAD와 내 커밋의 위치)을 정확히 이해하고, 파일 하나씩 차근차근 처리하는 습관만 들여도 다중 충돌 상황에서 훨씬 침착하게 대응할 수 있습니다. 판단이 서지 않을 때는 무리하게 밀어붙이기보다 rebase --abort로 되돌리고 다시 접근하는 것도 충분히 좋은 선택입니다.
