Git merge conflict가 났을 때 확인할 것

Git merge conflict가 났을 때 확인할 것에서 먼저 볼 부분

merge conflict는 같은 파일의 같은 부분이 서로 다르게 바뀌었을 때 Git이 자동으로 고르지 못해 멈춘 상태입니다. 표시를 읽고 의도에 맞게 정리해야 합니다.

conflict는 Git이 고장났다는 뜻이 아닙니다. 두 변경사항 중 무엇을 남겨야 할지 사람이 결정해야 하는 상황이라는 신호입니다.

파일 안에는 <<<<<<<, =======, >>>>>>> 표시가 들어갑니다. 위쪽은 현재 브랜치의 내용이고 아래쪽은 합치려는 브랜치의 내용입니다.

해결할 때는 표시 줄을 모두 지우고 최종적으로 남길 코드만 정리해야 합니다. 둘 중 하나만 고를 수도 있고, 두 내용을 합쳐 새 문장으로 만들 수도 있습니다.

수정 후에는 파일을 저장하고 git add, git commit으로 conflict 해결을 기록합니다. 이때 브라우저나 테스트로 결과를 확인한 뒤 커밋하는 습관이 좋습니다.

conflict 표시 예시

<<<<<<< HEAD
<h1>AG FE Guide</h1>
=======
<h1>Frontend Guide</h1>
>>>>>>> feature/title-change

이 예제는 그대로 복사해서 확인하는 것보다 한 줄씩 바꿔보는 쪽이 더 도움이 됩니다. 태그 이름, 선택자, 변수 이름, 함수 실행 위치를 조금씩 바꾸면 어떤 부분이 결과에 영향을 주는지 직접 확인할 수 있습니다.

잘못 작성했을 때 나타나는 흐름

Git 글은 명령어를 외우기보다 작업 전 상태, 기록할 파일, 원격 저장소 반영 순서로 나누어 보는 것이 좋습니다.

문제가 생겼을 때는 먼저 현재 브랜치와 변경 파일을 확인하고, 그다음 커밋 또는 원격 상태를 확인하는 순서가 안전합니다.

GitHub와 배포 글은 설정 화면과 DNS가 함께 얽히므로 한 번에 여러 설정을 바꾸기보다 하나씩 확인하는 편이 좋습니다.

브라우저에서 직접 확인하는 순서

먼저 화면에 나타나는 결과를 보고, 그다음 코드에서 방금 수정한 부분을 확인하세요. 결과가 예상과 다르다면 콘솔 오류, 파일 경로, 선택자 이름, 태그 닫힘, 실행 순서 중 하나가 흔한 원인입니다.

초보 단계에서는 정답 코드를 한 번에 외우기보다 실패한 코드와 수정한 코드를 나란히 비교하는 방식이 좋습니다. 이 글의 예제를 기준으로 작은 값을 바꿔보면 다음 글을 읽을 때도 기준이 더 선명해집니다.

실습 후 점검할 항목

• conflict 표시가 있는 파일 찾기
• 현재 브랜치와 상대 브랜치 내용을 구분하기
• 최종 코드만 남기고 표시 줄 삭제하기
• 해결 후 화면이나 테스트 확인하기