⚔️ Git 충돌(conflict) 해결 완벽 가이드 — 진짜 실무에서 겪는 상황별 정리
“분명 잘되던 코드인데, 갑자기 merge conflict 떴어요!”
협업을 시작하면 누구나 처음 마주하는 벽이 바로 Git 충돌(conflict) 이다.
이 문제는 피할 수는 없지만, 이해하면 쉽게 해결할 수 있다.
이번 글에서는
✅ 충돌이 왜 생기는지
✅ 어떤 방식으로 해결하는지
✅ 실무에서 가장 깔끔한 정리 루틴은 무엇인지
단계별로 완벽히 정리해보자.
💡 1. 충돌(conflict)이란?
“Git이 두 개의 수정 내용을 동시에 병합할 수 없을 때 발생하는 현상”
Git은 보통 자동으로 merge를 해준다.
하지만 두 브랜치에서 같은 파일의 같은 줄을 수정했다면,
Git은 “어느 쪽이 맞는지” 판단할 수 없기 때문에 충돌이 발생한다.
예를 들어 👇
- main 브랜치
- console.log("Hello world!");
- feature/login 브랜치
- console.log("Welcome user!");
이 상태에서 git merge feature/login을 하면?
Git은 두 버전 중 어느 것을 살려야 할지 몰라 충돌을 일으킨다.
⚙️ 2. 충돌 상황 확인하기
충돌이 발생하면 터미널에 이런 메시지가 뜬다 👇
Auto-merging index.js
CONFLICT (content): Merge conflict in index.js
Automatic merge failed; fix conflicts and then commit the result.
즉, index.js 파일 안에 수동으로 해결해야 할 코드가 생긴 것이다.
🧩 3. 충돌 코드의 구조
파일을 열어보면 이런 형태로 표시된다 👇
<<<<<<< HEAD
console.log("Hello world!");
=======
console.log("Welcome user!");
>>>>>>> feature/login
각 구분의 의미는 다음과 같다:
구분 의미
| <<<<<<< HEAD | 현재 브랜치 (병합 기준 브랜치) |
| ======= | 충돌 경계선 |
| >>>>>>> feature/login | 병합하려는 브랜치 |
💬 즉, HEAD는 내가 현재 있는 브랜치,
>>>>>>> 부분은 병합하려는 상대 브랜치의 코드다.
🔍 4. 수동으로 충돌 해결하기
이제 코드 중 하나를 선택하거나, 둘을 합쳐서 정리하면 된다.
예시 👇
console.log("Hello world! Welcome user!");
정리 후에는 꼭 구분선을 제거해야 한다.
✅ 이후 순서:
git add index.js
git commit -m "충돌 해결: index.js 수정"
💡 이 커밋이 바로 “충돌 해결 커밋”이다.
Git은 자동으로 병합 과정을 기록한다.
🧱 5. VSCode로 충돌 해결하기 (추천)
Git을 많이 쓰는 실무에서는 대부분 VSCode로 해결한다.
충돌이 생기면 VSCode가 친절하게 안내해준다 👇
- 파일을 열면
Accept Current Change, Accept Incoming Change, Accept Both Changes
버튼이 나타난다. - 클릭 한 번으로 원하는 버전 선택
- 수정 후 저장 → git add . → git commit
✅ 시각적으로 비교할 수 있어, 복잡한 충돌도 한눈에 해결 가능.
🧠 6. 충돌 발생 원인 3가지
유형 원인 예시
| 1. 같은 줄 수정 | 동일한 코드 라인에서 수정 발생 | 동일 함수명 수정 |
| 2. 파일 이름 변경 | 한쪽에서 이름 변경, 다른 쪽에서 수정 | index.js → main.js |
| 3. 삭제 vs 수정 | 한쪽은 파일 삭제, 다른 쪽은 수정 | merge 시 충돌 발생 |
💡 대부분은 같은 줄 수정이 원인이다.
작업 전에 git pull을 자주 해두면 예방 가능하다.
🔄 7. 충돌 예방을 위한 협업 규칙
✅ 1. 작업 시작 전 pull 필수
git pull origin main
✅ 2. 기능별로 브랜치 나누기
- feature/로그인
- feature/회원가입
→ 서로 다른 파일에서 작업하게 된다.
✅ 3. 커밋을 자주 쪼개기
- 작은 단위로 커밋하면 충돌 시 원인 파악이 쉽다.
✅ 4. merge 전 rebase로 깔끔히 정리
git fetch origin
git rebase origin/main
→ 최신 코드 위에 내 코드를 덮어서 충돌 범위를 최소화한다.
🧮 8. 충돌 해결 루틴 (정리 버전)
단계 명령어 설명
| 1 | git pull origin main | 최신 코드 동기화 |
| 2 | git merge feature/브랜치명 | 병합 시도 |
| 3 | 충돌 발생 시 수동 해결 | 구분선 제거 |
| 4 | git add . | 수정된 파일 등록 |
| 5 | git commit -m "충돌 해결" | 병합 완료 |
| 6 | git push | 원격 반영 |
💡 단순하지만, 이 루틴을 몸에 익히면 충돌 공포증이 사라진다.
⚡ 9. 실무 팁 — rebase vs merge 충돌 비교
구분 merge rebase
| 병합 형태 | 두 브랜치를 합쳐 새 커밋 생성 | 내 커밋을 위로 재적용 |
| 기록 형태 | 분기 흔적이 남음 | 직선 구조로 깔끔함 |
| 충돌 처리 | 한 번에 해결 | 각 커밋마다 해결해야 함 |
| 추천 상황 | 팀 단위, 공용 저장소 | 개인 작업 / 브랜치 정리 |
💬 협업 중이라면 merge,
개인 브랜치 정리용이라면 rebase가 안전하다.
🧭 10. 마무리 — “충돌은 실수의 신호가 아니라, 협업의 증거다”
충돌(conflict)은 나쁜 게 아니다.
오히려 팀이 동시에 열심히 작업하고 있다는 신호다.
Git은 “누가 어떤 걸 수정했는지”를 다 알고 있으니,
침착하게 비교하고 커밋만 하면 된다.
💬 “Git 충돌은 에러가 아니라, 대화의 시작이다.”
다음 편에서는
✅ stash, tag, cherry-pick 같은
고급 Git 기능으로 생산성을 높이는 방법을 배워보자.