내용이 'ab'인 매우 간단한 텍스트 문서 (text.txt)를 상상해보십시오. 이 파일은 정식 (원격) 저장소에서 체크인되었습니다. 두 사람이이 저장소를 로컬에서 닫고이 파일을 편집하고 편집을 시작합니다. Dan은 내용을 'aB'(자본 B 참고)로 변경하고 John은 자신의 버전을 'abc'로 편집합니다. Dan은 커밋을 수행하고이를 표준 저장소에 푸시합니다. John은 나중에 로컬 커밋을 수행하고 변경 사항을 원격으로 푸시합니다. John이 저장소를 푸시하면 어떻게됩니까 (메시지)?Dan이 텍스트를 'aB'로 변경하고 John을 'abc'로 변경하면 어떻게됩니까?
병합 충돌이 있습니다.
충돌이 없습니다. 요한의 밀어 넣기는 그가 멀리 나가는 지점의 직계 후손이 아니기 때문에 거부 될 것입니다.
John이 자신의 커밋을 푸시하기를 원하면 먼 지점의 커밋 인 커밋과 병합하거나 커밋 맨 위에 커밋을 리베트해야합니다. 이 시점에서 그는 텍스트 파일에서 충돌을 해결하는 방법을 선택해야합니다.
푸시 할 때 사용하는 플래그에 따라 다릅니다.
기본적으로 원격 지점 헤드 (Dan의 커밋)는 John의 수정본의 상위가 아니므로 밀어 넣기가 실패합니다.
-f 또는 --force으로 Dan의 변경 사항을 John의 것으로 덮어 씀으로써 Dan의 푸시를 효과적으로 취소 할 수 있습니다. 서버가 적어도 강제 푸시를 허용하도록 설정되어있는 경우입니다. 많은 자식 서버는 단순히이 작업을 거부합니다.
일반적으로 '올바른 방법'은 John이 정상적으로 푸시하려고 시도하는 것입니다. 그는 제가 언급 한 오류를보고 다른 누군가가 변화를 겪었다는 것을 알게 될 것입니다. 그런 다음 그는 git pull을 수행하여 Dan의 변경 사항을 검색하고 자신의 변경 사항을 병합합니다. 끌어 오기가 병합을 시도하여 텍스트 파일에서 충돌을 일으키고 John이 수정하도록 남겨 둡니다. John이 충돌을 해결하면 (아마도 파일에 'aBc'가 포함 된 다음 자식 디렉토리가 알려 지도록 git add text.txt; git commit을 사용하여) 로컬 저장소에 두 변경 사항을 모두 포함하는 것으로 표시된 '병합 완료'가 포함됩니다. 그런 다음 더 이상 문제없이 서버에 푸시 할 수 있습니다.
더 정확히 말하면, 병합 커밋에는 각 분기의 팁이 부모로 있습니다. 커밋 자체에는 두 가지 변경 내용이 모두 포함되어 있지 않지만 충돌의 해결 방법이 포함되어 있습니다. – Cascabel