Git 머지 충돌 해결하는 법, 4단계로 끝내기

Q: 충돌 파일을 add하지 않고 commit하면 어떻게 되나요?

fatal: Exiting because of an unresolved conflict 또는 이와 유사한 오류가 뜨며 커밋이 거부됩니다. Git은 충돌 표시가 남은 파일이 하나라도 add되지 않으면 병합을 완료시켜주지 않습니다.

Q: rebase 중 충돌은 merge 충돌과 다르게 처리해야 하나요?

파일 안의 마커를 읽고 코드를 정리하는 방식은 동일하지만, 마무리 명령이 다릅니다. rebase는 git add 후 git commit이 아니라 git rebase --continue를 실행해야 하고, 커밋 하나마다 충돌이 반복될 수 있어 여러 번 이 과정을 거칠 수 있습니다. 되돌리고 싶을 때는 git rebase --abort를 사용합니다.

Q: GUI 도구 없이 명령줄만으로 충돌을 해결할 수 있나요?

가능합니다. git status로 충돌 파일을 찾고, 텍스트 에디터로 마커 구간을 직접 정리한 뒤 git add, git commit만 실행하면 되므로 별도 도구 없이도 전 과정을 처리할 수 있습니다.

Git Merge 충돌, 왜 발생하고 어떻게 해결하나요?

feature와 main 브랜치가 같은 코드 줄을 다르게 수정해 발생한 Git 머지 충돌과 해결 과정

Git merge 충돌(conflict)은 두 브랜치가 같은 파일의 같은 줄을 서로 다르게 수정했을 때, Git이 어느 쪽 내용을 남겨야 할지 자동으로 판단하지 못해 발생합니다. 해결 방법은 간단히 말하면 ①충돌 파일 확인 → ②마커를 보고 직접 코드 정리 → ③git add로 해결 표시 → ④git commit으로 병합 완료의 4단계입니다. 아래에서 각 단계를 실제 명령어와 함께 순서대로 설명합니다.

충돌은 버그가 아니라 Git이 안전장치로 작동한 결과입니다. 두 사람이 같은 줄을 고쳤는데 Git이 임의로 하나를 지워버리면 더 큰 사고로 이어지기 때문에, Git은 판단을 사람에게 넘기고 작업을 잠시 멈춥니다. 즉 충돌 메시지가 떴다고 당황할 필요는 없고, 정해진 절차대로 처리하면 됩니다.

충돌 해결 전에 반드시 확인할 것

git status로 충돌 파일 목록 확인하기

merge나 pull 도중 충돌이 나면 터미널에 CONFLICT (content): Merge conflict in 파일명 메시지가 뜨고 병합이 중단됩니다. 이때 가장 먼저 할 일은 git status 실행입니다. both modified: 표시가 붙은 파일이 바로 충돌이 난 파일이며, 프로젝트 규모가 크면 한 번에 여러 개가 나올 수 있습니다.

git status
# On branch main
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Unmerged paths:
#   both modified:   src/app.js

충돌 마커의 의미 이해하기

충돌이 난 파일을 열면 Git이 삽입한 특수 기호(충돌 마커)가 보입니다. 이 기호가 어떤 의미인지 모른 채 임의로 지우면 코드가 깨지므로 정확히 이해하고 시작해야 합니다.

<<<<<<< HEAD — 이 줄부터 =======까지는 현재 내가 있는 브랜치(보통 작업 중이던 브랜치)의 내용입니다.
======= — 두 브랜치의 내용을 구분하는 경계선입니다.
>>>>>>> 브랜치명 — 이 줄 위까지는 병합하려는 상대 브랜치의 내용입니다.

<<<<<<< HEAD
const LIMIT = 10;
=======
const LIMIT = 20;
>>>>>>> feature-limit-update

충돌 마커(<<<<<<<, =======, >>>>>>>) 세 줄을 전부 지우지 않고 커밋하면 마커 문자열 자체가 코드에 그대로 남아 빌드 에러나 실행 오류의 원인이 됩니다. 편집이 끝나면 파일 안에 마커가 하나도 남아있지 않은지 반드시 다시 확인하세요.

Git Merge 충돌 해결 4단계 (실전 절차)

충돌 마커 확인, 코드 수정, git add, git commit으로 이어지는 Git 머지 충돌 해결 4단계

충돌이 발생했을 때 실제로 따라야 하는 순서는 다음과 같습니다.

충돌 파일을 열어 마커 위치를 확인한다
어떤 코드를 남길지 판단해 직접 편집한다
git add로 해결 완료를 Git에 알린다
git commit으로 병합을 마무리한다

1단계: 충돌 파일 열어 마커 확인하기

에디터에서 충돌 파일을 열면 위에서 본 세 개의 마커 사이에 두 버전의 코드가 나란히 보입니다. 파일 하나에 충돌 구간이 여러 곳일 수 있으므로, 에디터의 검색 기능으로 <<<<<<<를 검색해 모든 충돌 구간을 빠짐없이 찾는 것이 좋습니다.

2단계: 어떤 코드를 남길지 직접 편집하기

내 브랜치 코드를 남길지, 상대 브랜치 코드를 남길지, 아니면 둘을 합쳐서 새 코드로 정리할지는 Git이 아니라 사람이 판단해야 합니다. 최종 코드만 남기고 <<<<<<<, =======, >>>>>>> 세 줄은 전부 삭제합니다. 팀 협업 중이라면 상대 브랜치 작성자와 슬랙·메신저로 의도를 확인하고 병합하는 것이 안전합니다.

3단계: git add로 해결 완료 표시하기

편집이 끝난 파일은 git add 파일명으로 스테이징합니다. 이 명령이 Git에게 "이 파일의 충돌은 해결됐다"고 알리는 신호입니다. 충돌 파일이 여러 개라면 모두 add해야 다음 단계로 넘어갈 수 있습니다.

git add src/app.js
git status
# All conflicts fixed but you are still merging.

4단계: 커밋으로 병합 마무리하기

모든 충돌 파일을 add했다면 git commit만 실행하면 됩니다. 메시지를 따로 입력하지 않아도 Git이 자동으로 "Merge branch..." 형태의 커밋 메시지를 채워주며, 이 커밋으로 병합이 완전히 종료됩니다.

git commit
# 자동 생성된 병합 메시지를 그대로 저장하거나 필요시 수정

상황별 충돌 해결법

git pull 도중 충돌 났을 때

git pull은 내부적으로 fetch(원격 정보 가져오기) 후 merge를 실행하는 명령이라, pull 중 충돌은 merge 충돌과 해결법이 동일합니다. 다만 커밋을 마무리하지 않은 채 다시 pull을 시도하면 You have not concluded your merge (MERGE_HEAD exists) 오류가 나므로, 위 4단계를 먼저 끝낸 뒤 push하는 순서를 지켜야 합니다.

충돌 해결을 취소하고 되돌리고 싶을 때

편집하다가 너무 복잡해져서 병합 자체를 취소하고 싶다면 git merge --abort를 사용합니다. 이 명령은 merge를 시작하기 직전 상태로 완전히 되돌려주므로, 커밋을 하기 전이라면 언제든 안전하게 재시도할 수 있습니다.

git merge --abort
git status
# 병합 이전 상태로 복원됨

VS Code·mergetool로 시각적으로 해결하기

텍스트 마커만으로 판단이 어렵다면 VS Code 같은 에디터의 병합 편집기를 쓰면 "현재 변경 사항 수락", "수신 변경 사항 수락", "두 변경 사항 모두 수락" 버튼으로 클릭만으로 해결할 수 있습니다. Git 2.47(2024년 10월 출시) 이상을 쓰고 있다면 명령줄에서 git config --global merge.tool vscode 한 줄만 등록해도 git mergetool 실행 시 VS Code가 바로 열립니다. 다만 그보다 오래된 Git이라면(vscode가 내장 프리셋으로 추가되기 전 버전) 아래 명령어를 추가로 등록해야 git mergetool이 VS Code를 정상적으로 실행합니다. 현재 쓰고 있는 Git 버전은 git --version으로 확인할 수 있습니다.

git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait --merge $REMOTE $LOCAL $BASE $MERGED'

최근에는 Claude Code 같은 CLI 기반 AI 코딩 도구에 충돌 파일을 보여주고 두 코드의 의도를 요약해 병합 제안을 받는 방식도 함께 활용하는 경우가 늘고 있습니다.

Merge vs Rebase, 언제 무엇을 써야 할까

브랜치 병합 이력을 유지하는 Git Merge와 커밋을 직선형으로 재배치하는 Rebase 비교

충돌은 merge뿐 아니라 rebase(브랜치의 커밋을 다른 브랜치 위로 재배치하는 방식) 중에도 발생합니다. 두 방식은 충돌 처리 명령어부터 다르므로 구분이 필요합니다.

구분	Merge	Rebase
히스토리 형태	병합 커밋이 남아 분기·합류가 그대로 보임	커밋이 한 줄로 재배열되어 히스토리가 깔끔함
충돌 해결 후 명령	`git add` → `git commit`	`git add` → `git rebase --continue`
충돌 시 취소 명령	`git merge --abort`	`git rebase --abort`
추천 상황	공유 브랜치, 협업 이력을 그대로 남기고 싶을 때	개인 작업 브랜치를 정리해 PR 올리기 전

충돌을 애초에 줄이는 방법

충돌 자체를 없앨 수는 없지만, 발생 빈도와 해결 난이도는 습관으로 크게 줄일 수 있습니다.

작업 시작 전 git pull 또는 git fetch로 최신 코드를 먼저 받아온다
기능 단위로 브랜치를 짧게 유지하고 자주 병합해 변경 범위를 작게 가져간다
여러 사람이 같은 파일을 동시에 오래 붙잡고 있지 않도록 작업을 사전에 조율한다
포맷터·들여쓰기 스타일을 팀 전체가 통일해 불필요한 줄 단위 충돌을 줄인다
커밋을 잘게 나눠 커밋 메시지만 봐도 변경 의도를 파악할 수 있게 한다

자주 묻는 질문

Q. 충돌 해결 중에 다른 브랜치로 이동해도 되나요?

권장하지 않습니다. 병합이 진행 중인 상태(unmerged)에서 브랜치를 전환하면 오류가 나거나 작업 내용이 꼬일 수 있으므로, 충돌을 끝까지 해결해 커밋을 완료하거나 git merge --abort로 취소한 뒤에 이동하는 것이 안전합니다.

Q. 충돌 파일을 add하지 않고 commit하면 어떻게 되나요?

fatal: Exiting because of an unresolved conflict 또는 이와 유사한 오류가 뜨며 커밋이 거부됩니다. Git은 충돌 표시가 남은 파일이 하나라도 add되지 않으면 병합을 완료시켜주지 않습니다.

Q. 충돌 마커가 남은 채로 실수로 push했다면 어떻게 하나요?

파일을 다시 열어 남아있는 마커를 지우고 정상 코드로 수정한 뒤 새 커밋으로 push하면 됩니다. 이미 배포된 상태라면 빌드나 서비스가 깨졌는지부터 확인하고, 문제가 크면 이전 정상 커밋으로 되돌리는 revert를 우선 적용한 뒤 차분히 재작업하는 것이 안전합니다.

Q. rebase 중 충돌은 merge 충돌과 다르게 처리해야 하나요?

파일 안의 마커를 읽고 코드를 정리하는 방식은 동일하지만, 마무리 명령이 다릅니다. rebase는 git add 후 git commit이 아니라 git rebase --continue를 실행해야 하고, 커밋 하나마다 충돌이 반복될 수 있어 여러 번 이 과정을 거칠 수 있습니다. 되돌리고 싶을 때는 git rebase --abort를 사용합니다.

Q. GUI 도구 없이 명령줄만으로 충돌을 해결할 수 있나요?

가능합니다. git status로 충돌 파일을 찾고, 텍스트 에디터로 마커 구간을 직접 정리한 뒤 git add, git commit만 실행하면 되므로 별도 도구 없이도 전 과정을 처리할 수 있습니다.