github에서 다운로드한 소스코드는 기본적으로 git Warehouse가 아니기 때문에 다운로드한 코드를 git Warehouse로 초기화하면 해당 웨어하우스에는 제출 이력이 없습니다. 두 창고 가 동일한 이력이 아닌 경우 git pull을 사용하여 원격 창고에 병합할 수 없으므로 처음에 사용한 방법으로 인해 다음 오류가 발생합니다.

관련 없는 이력 병합 거부

그러나 --allow-unrelated-histories 옵션을 사용하여 강제로 병합하면 문제가 해결됩니다.
그러나 나중에 겪게 되는 문제는 정상적인 것입니다. Git은 귀하의 콘텐츠와 작성자의 콘텐츠가 완전히 다른 두 개의 사본이라고 생각하지 않습니다. 단지 두 콘텐츠가 충돌하는 것, 즉 동일한 장소에 차이가 있을 뿐입니다. 충돌이 발생하면 수동으로 해결하세요. 그리고 내 추측에 따르면 충돌의 이유는 아마도 Windows 줄 바꿈과 Unix 줄 바꿈이 일관되지 않기 때문일 것입니다(물론 육안으로는 볼 수 없습니다). 이는 줄 바꿈을 처리하는 방법에 따라 다릅니다. 자식 설정. 아마도 원격 창고의 개행 문자는 Unix 개행 문자(LF) 또는 Windows 개행 문자(CLF)를 균일하게 사용하는데, 여러분은 그 반대일 수도 있습니다. Git 설정에서 줄 바꿈을 처리하는 방법은 github의 공식 도움말 문서를 참조할 수 있습니다. 물론 인터넷에도 많은 정보가 있습니다.
또한, 이전에 마스터가 말했듯이 git clone 명령을 사용하여 창고를 직접 복제하는 것이 가장 좋습니다. 그러면 창고의 기록 제출을 유지할 수 있고, 보고를 피하기 위해서는 git pull 명령을 사용하는 것이 좋습니다. 오류.

충돌되는 부분을 표시하며, 충돌을 해결하기 위해 어떤 부분을 유지할 것인지 선택할 수 있습니다.

또한 코드 복사본만 복사하고 포크하고 싶지 않은 경우 git clone만 하면 원격 호스트가 여전히 작성자의 것이며 git pull를 사용하여 유지할 수 있습니다. 앞으로 업데이트될 예정입니다

동일한 줄이 수정되어 GIT가 이를 인식하고 병합할 수 없기 때문입니다. GIT에서는 이를 冲突

충돌을 수동으로 해결한 다음 커밋해야 합니다. 충돌을 해결하는 방법은 "GIT 충돌 해결"

member 님의 답변이 이미 정확합니다. .
git add -u를 사용하여 충돌 파일을 추가할 수 있습니다. 그런 다음 git commit -m 커밋을 한 다음 git pull
언급한 상황이 발생하는 이유에 대해 설명합니다.
귀하의 코드는

222
여기에는 실제로 캐리지 리턴이나 라인 피드 기호 또는 기타

작성자 버전은
111
222
333

이 경우 git은 이것이 충돌임을 ​​인식하고 자동으로 병합되지 않습니다. 확실하지 않습니다. git은 코드를 자동으로 병합하지 않습니다.

@Fighting_Bird
테스트 후에는

• text=auto
  이 옵션, 설정에 이 옵션이 있으면 git은 제출하기 전에 LF로 간주하는 텍스트 문서의 모든 줄 바꿈을 변경하고 체크 아웃할 때 변경합니다. 그런 다음 다시 변환하지만 내 프로젝트에는 이 설정이 없으므로 그러한 변환 작업이 없으므로 문서 줄 바꿈이 달라지고 병합이 실패합니다