빠른 흐름

# 1. 충돌 파일 확인
git status

# 2. 파일 안의 충돌 마커를 직접 편집해 최종 내용 결정
# <<<<<<< HEAD
# 현재 브랜치 내용
# =======
# 병합 대상 브랜치 내용
# >>>>>>> feature/login

# 3. 해결 완료 표시
git add <file>

# 4. 진행 계속
git merge --continue   # merge 중이었다면
git rebase --continue  # rebase 중이었다면

해결 흐름

어떤 충돌 해결 흐름을 먼저 떠올리면 되나

conflict는 오류가 아니라 Git이 판단을 위임하는 신호다

Git이 두 브랜치의 변경을 자동으로 합칠 수 있을 때는 merge commit을 조용히 만든다. 하지만 같은 파일의 같은 줄 영역이 양쪽에서 다르게 수정됐을 때 Git은 "어느 쪽이 의도된 최종 상태인가"를 알 수 없다. 내부적으로는 index(스테이징 영역)에 stage 1(공통 조상), stage 2(ours), stage 3(theirs) 세 버전이 동시에 저장되며, Git은 작업 트리에 충돌 마커를 써서 사람의 결정을 기다린다. 이는 에러가 아니라 설계된 위임 동작이다. 당황하지 않고 먼저 git status로 어떤 파일이 영향을 받았는지 파악하는 것이 첫 번째다.

merge 중 충돌과 rebase 중 충돌은 해결 흐름이 다르다

merge 중 충돌은 한 번에 모든 파일 충돌을 해결하고 git merge --continue를 한 번 실행한다. rebase 중 충돌은 커밋을 하나씩 새로운 부모 위에 재배치하는 구조이므로, 충돌이 여러 커밋에 걸쳐 반복될 수 있다. 각 커밋마다 충돌을 해결하고 git rebase --continue를 반복해야 한다. 중간에 포기하고 싶다면 --abort로 원래 상태로 안전하게 되돌릴 수 있다. 현재 어떤 상태인지 불확실하면 git status가 항상 다음 단계를 안내해 준다.

# merge 충돌
git merge feature/login
git add app.js
git merge --continue

# rebase 충돌
git rebase origin/main
git add app.js
git rebase --continue
git add config.js
git rebase --continue

충돌 마커를 지우는 것과 올바른 코드를 선택하는 것은 다르다

충돌 마커(<<<<<<<, =======, >>>>>>>)를 제거하는 작업과, 두 변경 의도를 이해해 더 올바른 최종 코드를 결정하는 작업은 다른 문제다. 기계적으로 한쪽 버전만 남기면 컴파일은 되어도 로직이 조용히 깨질 수 있다. 특히 양쪽 브랜치가 각자 버그를 수정했거나 같은 기능을 다른 방식으로 구현한 경우, 두 변경을 모두 반영해야 올바른 결과가 나온다. 충돌 해결 직후 반드시 관련 테스트와 빌드를 확인해야 하는 이유가 여기 있다.

충돌을 줄이는 방법은 해결 기술보다 예방 습관에 있다

충돌 빈도는 브랜치 수명과 코드 경계 설계에 강하게 영향받는다. 수명이 긴 feature 브랜치일수록 main과 벌어질 시간이 많아 충돌 범위도 커진다. 작업 브랜치를 짧게 유지하고, git fetch + git rebase origin/main으로 자주 동기화하고, 여러 사람이 같은 파일을 동시에 편집하지 않도록 코드 경계를 명확히 하는 것이 충돌 해결 스킬보다 장기적으로 더 가치 있는 습관이다.

<<<<<<< HEAD
return formatPrice(total);
=======
return total.toString();
>>>>>>> feature/checkout

# 마커만 지우고 한쪽만 남기면
# 다른 브랜치의 수정 의도가 통째로 사라질 수 있음

체크포인트

주의할 점