충돌(conflict)이 발생했을 때 안전하게 해결하는 절차를 설명해주세요.
답변 포인트
변경 의도 이해와 검증를 기준으로 정의, 장점, 한계, 예시를 함께 설명해보세요.
정답 및 해설
빠른 요약
충돌 해결은 양쪽 변경 의도를 이해하고 필요한 코드를 통합하는 과정입니다. marker 제거 후 관련 테스트와 빌드로 결과를 확인해야 합니다.
충돌 해결은 양쪽 변경 의도를 이해하고 필요한 코드를 통합하는 과정입니다. marker 제거 후 관련 테스트와 빌드로 결과를 확인해야 합니다.
핵심 개념
핵심 기준은 변경 의도 이해와 검증입니다.
conflict는 Git이 같은 위치의 변경을 자동으로 합칠 수 없을 때 발생합니다. ours/theirs 중 하나를 기계적으로 고르기보다 두 변경이 해결하려던 문제를 이해하고 최종 코드가 둘 다 만족하는지 확인해야 합니다.
동작 흐름
- 현재 브랜치의 상태와 변경 범위를 먼저 확인합니다.
- 명령이 히스토리, 브랜치 포인터, 작업 디렉터리 중 무엇을 바꾸는지 구분합니다.
- 공유 브랜치에 영향을 주는 작업인지 확인합니다.
- 실행 후
git status와git log --oneline --graph로 결과를 검증합니다.
실제 예시
[현재 브랜치 변경]
현재 브랜치에서 수정한 내용
--- 충돌 구분선 ---
[병합하려는 브랜치 변경]
feature 브랜치에서 수정한 내용실제 파일에는 Git이 <<<<<<<, =======, >>>>>>> 형태의 충돌 마커를 남깁니다. 이 마커를 그대로 커밋하면 안 되고, 최종적으로 남길 내용을 직접 정리한 뒤 마커를 모두 제거해야 합니다.
예시는 핵심 흐름을 단순화한 것입니다. 실무에서는 팀의 배포 방식, 데이터 크기, 장애 영향도, 유지보수 비용까지 함께 고려해야 합니다.
실무에서 주의할 점
- 공유된 히스토리를 재작성하면 동료의 로컬 작업과 충돌할 수 있습니다.
- 충돌 해결은 한쪽 선택이 아니라 양쪽 변경 의도를 통합하는 과정입니다.
- 위험한 작업 전에는 임시 브랜치나 태그로 복구 지점을 남기면 안전합니다.
함께 연결해서 보면 좋은 키워드
Git, Conflict, Merge, Collaboration
정리
한 줄로 정리하면, 충돌 해결은 양쪽 변경 의도를 이해하고 필요한 코드를 통합하는 과정입니다. marker 제거 후 관련 테스트와 빌드로 결과를 확인해야 합니다. 개념의 정의뿐 아니라 적용 조건과 실패했을 때의 증상까지 함께 이해하는 것이 중요합니다.