Git Rebase vs Merge 충돌(Conflict) 해결 및 깔끔한 커밋 히스토리 관리 전략

9월 23, 2026

Git Rebase vs Merge 충돌(Conflict) 해결 및 깔끔한 커밋 히스토리 관리 전략

"금요일 퇴근 10분 전, 야심 차게 개발한 기능을 서버에 올리려고 git push를 날렸는데, 화면을 붉게 물들이는 Merge conflict 에러 메시지에 식은땀을 흘려본 적 있으신가요?"

다수의 개발자가 하나의 프로젝트(Repository)에서 협업할 때 Git 충돌은 피할 수 없는 숙명입니다. 그러나 초보 개발자들은 충돌이 두려워 무작정 git pull과 git merge만을 반복하며, 결과적으로 프로젝트의 커밋(Commit) 히스토리를 거미줄처럼 얽힌 '스파게티 히스토리'로 만들어버립니다.

얽히고설킨 히스토리는 장애 발생 시 원인이 되는 코드를 추적(Track)하거나 이전 상태로 롤백(Rollback)하는 것을 불가능하게 만듭니다. 본 가이드에서는 지저분한 Merge 커밋을 방지하고, 엔터프라이즈급 개발팀이 선호하는 선형적이고 깔끔한 커밋 히스토리를 구축하는 Rebase 아키텍처와 충돌 해결법을 단호하게 제시합니다.

📌 이 글의 핵심 포인트

거미줄 히스토리를 유발하는 git merge의 한계와 작동 원리

커밋의 기저(Base)를 다시 설정하여 선형적 히스토리를 만드는 git rebase 전략

안전한 협업을 위한 Rebase 중단(Abort) 및 충돌(Conflict) 단계별 해결 가이드

1단계: 핵심 원인 분석 - 스파게티 히스토리의 탄생

내가 feature-A 브랜치에서 작업하는 동안, 동료가 main 브랜치에 새로운 코드를 업데이트했다고 가정해 봅시다. 내 로컬 코드에 동료의 최신 코드를 반영하기 위해 git merge main을 실행하면, Git은 두 브랜치의 역사를 합치는 새로운 '병합 커밋(Merge Commit)'을 억지로 하나 생성합니다.

이 작업이 10명의 개발자에 의해 하루에도 수십 번씩 일어난다면? 커밋 로그는 Merge branch 'main' into feature-A라는 무의미한 메시지로 도배되며, 코드의 실제 발전 흐름을 전혀 파악할 수 없는 상태에 이릅니다.

2단계: 완벽한 해결책 - Rebase를 통한 선형적 히스토리 구축

Rebase(리베이스)는 단어 그대로 '브랜치가 갈라져 나온 뿌리(Base)를 다시(Re) 설정한다'는 뜻입니다. 동료의 최신 커밋들 위로 내 작업물들을 살포시 올려놓아, 마치 처음부터 내가 동료의 작업 이후에 코드를 짠 것처럼 히스토리를 일직선(Linear)으로 조작합니다.


# 1. 원격 저장소의 최신 main 브랜치 코드를 가져옵니다.
git fetch origin main

# 2. 내 현재 작업 브랜치(feature-A)에서 rebase를 실행합니다.
git rebase origin/main

# 3. 히스토리가 깔끔하게 일직선으로 정리된 후 서버에 강제 푸시합니다.
# (내 로컬의 히스토리가 조작되었으므로 강제 푸시가 필요함)
git push --force-with-lease origin feature-A

여기서 주의할 점은, --force 대신 반드시 --force-with-lease를 사용해야 한다는 것입니다. 이는 내가 모르는 사이 원격 브랜치에 다른 누군가 코드를 푸시했다면 덮어쓰기를 멈춰주는 강력한 안전장치입니다.

3단계: 실무 트러블슈팅 - Rebase 충돌(Conflict)의 완벽한 제어

Rebase를 실행하다가 동일한 파일의 같은 라인을 동료와 내가 모두 수정했다면 CONFLICT (content) 에러와 함께 프로세스가 일시 정지됩니다. 당황하지 말고 아래 3단계를 수행하십시오.

충돌 파일 수정: VS Code 등의 에디터를 열어 충돌이 발생한 파일 내의 <<<<<<< HEAD (동료의 최신 코드)와 >>>>>>> (내 코드) 부분을 확인하고, 남길 코드를 정리한 뒤 꺽쇠 기호들을 모두 삭제합니다.
수정 사항 스테이징: 터미널에 git add 충돌해결된파일.js를 입력하여 해결된 파일을 Git에 알립니다. (여기서 절대 git commit을 치면 안 됩니다!)
Rebase 재개: git rebase --continue를 입력하면 다음 커밋으로 넘어가며 프로세스가 다시 진행됩니다.

만약 충돌이 너무 심하게 나서 처음부터 다시 하고 싶다면? 언제든지 git rebase --abort를 입력하면 Rebase를 시도하기 전의 완벽하게 안전한 상태로 즉시 타임머신을 탑니다.

💡 아키텍트의 시선 (Insight)

Git 커밋 히스토리는 단순한 백업 데이터베이스가 아닙니다. 프로젝트에 새로 합류한 팀원과 6개월 뒤의 '나 자신'에게 코드의 발전 과정을 설명해 주는 가장 완벽한 기술 문서입니다. "이 기능은 왜 추가되었고, 어떤 코드들이 변경되었는가?"를 한눈에 파악할 수 있도록, Rebase를 적극 활용하여 노이즈 없는 우아한 히스토리 아키텍처를 구축하십시오.

이 블로그 검색

HAGOCUBE | 디지털 생산성 아키텍트