conflict 는 실패가 아니라 review 야
처음 Git 이 merge 중에 "CONFLICT (content):" 로 멈추면 본능적으로 패닉이야. 그건 틀려. conflict 는 Git 이 추측 거부를 제대로 한 거야. 두 branch 가 같은 줄을 바꿨고 Git 은 누구 의도가 맞는지 결정 못 해 — 네가 결정해. conflict 를 통합의 정상적인 일부로 보는 것 — 뭔가 망가졌다는 신호가 아니라 — 이게 merge 무서워하는 사람과 매일 ship 하는 사람의 차이야.
conflict 나면 Git 이 영향 받은 파일에 conflict marker 삽입. <<<<<<< HEAD 와 ======= 사이는 네 쪽. ======= 와 >>>>>>> other-branch 사이는 들어오는 쪽. 네 역할: 파일이 어떻게 생겨야 할지 결정, 그렇게 편집, marker 제거, git add. 충돌한 파일 다 add 하면 git commit 으로 merge 마무리. git status 가 이 과정을 계속 안내해.
해결 동작 셋이 대부분 케이스 커버. 한쪽 통째로 채택 — 들어오는 변경이 맞고 local 버릴 수 있을 때: git checkout --ours file 또는 git checkout --theirs file, add. 둘 다 손으로 합치기 — 양쪽 변경이 다 필요할 때, list 추가, import, config 에 흔해. 새로 짜기 — 어느 쪽도 단독으로는 옳은 동작 못 잡을 때, merged version 이 양쪽 input 과 다른 logic conflict 에 흔해.
merge 시작했는데 나가고 싶으면: git merge --abort 로 merge 전 상태로 rewind, 흔적 없음. 해결 끝내고 push 했으면 abort 못 해, 대신 git revert -m 1 <merge-hash> 로 merge content 를 undo (merge commit 의 history 모양은 유지). 탈출구는 실재해 — 해결 commit 전까지 conflict 는 reversible.