Git 끔찍한 병합 충돌(Merge Conflict) 방어: Rebase와 Squash 아키텍처
Git 끔찍한 병합 충돌(Merge Conflict) 방어: Rebase와 Squash 아키텍처
"동료와 각자 브랜치에서 며칠 동안 작업한 뒤 코드를 합치기 위해 git merge를 쳤더니, 터미널에 시뻘건 글씨로 충돌(Conflict)이 났다고 뜨며 코드 전체가 기괴한 꺾쇠(<<<<<<) 기호로 오염되었습니다."
실무에서 팀 프로젝트를 진행하는 모든 개발자가 겪는 가장 두려운 순간입니다. 누구의 코드가 맞는지 몰라 엉겁결에 상대방의 코드를 지워버리고 강제 커밋을 날렸다가 프로덕션 서버 전체를 망가뜨리는 대참사가 벌어지곤 합니다.
충돌은 도구의 문제가 아닙니다. 커뮤니케이션의 부재와 '시간의 흐름'을 통제하지 못한 결과입니다. 초보자들은 충돌이 날까 두려워 merge 버튼만 소심하게 누르며 지저분한 스파게티 커밋 로그를 양산합니다. 본 가이드에서는 git rebase를 통해 코드의 시공간을 재배열하여 선형적이고 예술적인 커밋 히스토리를 유지하는 엔터프라이즈 버전 관리 전략을 단호하게 제시합니다.
📌 이 글의 핵심 포인트
- Merge Conflict의 본질: 동일한 파일, 동일한 라인을 동시에 수정한 시공간의 엇갈림
- Merge의 한계와 Rebase의 차이점: 커밋의 베이스(Base)를 최신으로 옮기는 원리
- 대화형 리베이스(Interactive Rebase)를 통한 불필요한 커밋 스쿼시(Squash) 병합 기술
1단계: 에러의 본질 - 무의미한 Merge Commit의 축적
일반적으로 내 브랜치에서 작업을 끝내고 메인(Main) 브랜치와 합칠 때 git merge를 사용합니다. 하지만 내가 작업하는 이틀 동안, 다른 동료가 이미 메인 브랜치에 자신의 코드를 반영해 두었다면 베이스가 엇갈리게 됩니다.
이 상태에서 합치게 되면 Git은 두 세계를 억지로 이어붙이는 'Merge commit'을 강제로 생성합니다. 팀원 5명이 하루에 몇 번씩 이 짓을 반복하면, 깃허브의 커밋 그래프는 수없이 갈라지고 합쳐지는 흉측한 지하철 노선도처럼 변해버려 나중에 버그를 추적(Git Bisect)하는 것이 불가능해집니다.
2단계: 완벽한 해결책 - Rebase로 바탕(Base)을 다시 깔아라
Rebase(리베이스)는 단어 그대로 '바탕을 다시 잡는다'는 뜻입니다. 내 작업 내역을 잠시 공중에 띄워두고, 동료가 새롭게 업데이트한 메인 브랜치의 최신 코드를 내 바탕으로 깔아버립니다. 그리고 그 최신 코드 위에 내 커밋들을 하나씩 차례대로 다시 올려놓는(Re-apply) 과정입니다.
# 1. 원격 저장소의 최신 상태를 로컬로 업데이트
git fetch origin
# 2. 내 작업 브랜치에서, 최신 main 브랜치를 기준으로 리베이스 실행
git rebase origin/main
# 3. 만약 중간에 충돌이 난다면, IDE(VSCode)에서 코드를 수정한 뒤 이어서 진행
git add .
git rebase --continue
이 방식을 사용하면 나뭇가지가 갈라진 흔적이 전혀 없이, 마치 내가 처음부터 최신 코드 위에서만 작업한 것처럼 일직선(Linear)의 아름다운 커밋 히스토리를 유지할 수 있습니다. 이미 리베이스 단계에서 충돌을 다 해결했기 때문에 GitHub에 PR(Pull Request)을 올리면 100% 무결점으로 통과됩니다.
3단계: 지저분한 로그 세탁 - Interactive Squash
작업하다 보면 "오타 수정", "진짜 최종", "진짜진짜 최종" 같은 부끄러운 커밋이 수십 개씩 쌓입니다. 이때 git rebase -i HEAD~5 (최근 5개 커밋 대상) 명령어를 치면 마법이 일어납니다. 대화형 에디터 창에서 합치고 싶은 자잘한 커밋 앞의 pick 글자를 squash로 바꾸어주면, 여러 개의 커밋이 깔끔하고 논리적인 하나의 커밋으로 압축됩니다.
🙋♂️ 자주 묻는 질문 (FAQ)
Q. Rebase 도중 코드가 꼬여서 수습이 안 되면 어떡하나요?
A. 당황하지 말고 터미널에 git rebase --abort를 입력하십시오. 타임머신처럼 리베이스를 시작하기 직전의 상태로 완벽하게 되돌아갑니다.
Q. 이미 리모트 저장소에 푸시(Push)한 브랜치도 Rebase해도 되나요?
A. (경고) 다른 사람과 공유하는 브랜치(main, develop 등)에서는 절대 Rebase를 하면 안 됩니다. 커밋의 해시(Hash) 아이디가 전부 바뀌기 때문에 동료들의 로컬 저장소와 완전히 엇갈려 대재앙이 일어납니다. Rebase는 '나 혼자 작업 중인 로컬 피처 브랜치'에서만 사용해야 합니다.
💡 핵심 정리 및 마무리
Git은 코드를 저장하는 단순한 백업 툴이 아니라, 수많은 천재들이 충돌 없이 거대한 아키텍처를 쌓아 올리기 위해 발명한 정교한 시공간 기록 장치입니다. 충돌을 두려워해 더러운 히스토리를 방치하지 말고, Rebase와 Squash를 통해 코드의 역사를 예술적으로 재설계하는 전문가적 태도를 갖추시기 바랍니다.
댓글
댓글 쓰기