--depth 1로 얕은 복제하고 커밋을 만들고 업데이트를 다시 가져 오는 것이 안전합니까?

의 --depth 1옵션 git clone:

지정된 수의 개정판으로 기록이 잘린 얕은 복제본을 만듭니다 . 얕은 저장소에는 여러 가지 제한이 있지만 (복제하거나 가져올 수 없으며, 밀어 넣거나 넣을 수는 없습니다), 오랜 역사를 가진 대규모 프로젝트의 최근 기록에만 관심이 있고 적절할 경우 적합합니다. 수정 사항을 패치로 보내십시오.

그러나 얕은 복제를 성공적으로 수행하고 일부 변경 사항을 커밋 하고 해당 변경 사항 을 (맨 복제본) 원본으로 다시 푸시했습니다 .

그것은 나에게 의미가 있습니다-왜 안됩니까? 복제 된 HEAD가 출처에서 식별 가능하고 내 커밋이이 위에 올 때 이유가 없습니다. 그러나 매뉴얼은 그렇지 않다고 말합니다.

나는 얕은 복제의 아이디어를 좋아합니다-예를 들어 드루팔 코어 : 7에서 시작했을 때 드루팔 4에서 무슨 일이 있었는지 알 필요가 없습니다.

얕은 복제, 커밋 개발, 다시 시작하여 업데이트를 유지하는 것이 안전합니까?

Git 1.9 / 2.0 (2014 년 1 분기)은 이러한 제한 을 제거 했습니다.
참조 82fba2b 커밋 에서, (응웬 타이 응옥 두이 pclouds) :

git이 얕은 복제본으로 또는 얕은 복제본으로의 데이터 전송을 지원하므로 이러한 제한은 더 이상 적용되지 않습니다.

이제 설명서는 다음과 같습니다.

--depth <depth>::

지정된 수의 개정판으로 기록이 잘린 '얕은'복제본을 만듭니다.

얕은 클론과의 클론, send-pack / receive-pack을 지원하는 0d7d285 , f2c681c 및 c29a7b8 과 같은 커밋에서 비롯됩니다 .
smart-http는 이제 얕은 페치 / 클론도 지원합니다 .

모든 세부 사항은 " shallow.c: 새 커밋을 선택하는 8 단계.git/shallow "에 있습니다.

2015 년 6 월 업데이트 : Git 2.5는 단일 커밋 을 가져올 수 있습니다 !
(궁극의 얕은 케이스)

2016 년 1 월 업데이트 : Git 2.8 (2016 년 3 월)은 공식적으로 최소한의 역사를 얻는 관행을 문서화합니다.
참조 99487cf 커밋 , 9cfde9e 커밋 (12월 30일 2015) 9cfde9e을 커밋 (2015 12월 30일) bac5874 커밋 (2015 12월 29일)를, 그리고 1de2e44 커밋 에 의해 (2015년 12월 28일를) (``) 스티븐 P. 스미스 .
^{( Junio ​​C gitsterHamano 에 의해 병합 -- 커밋 7e3e80a , 2016 년 1 월 20 일)}

이것은 " Documentation/user-manual.txt"입니다

스위치 <<def_shallow_clone,shallow clone>>를 지정하여 A를 git-clone --depth만듭니다.
나중에 git-fetch --depth스위치 로 깊이를 변경 하거나으로 전체 기록을 복원 할 수 --unshallow있습니다.

병합 <<def_shallow_clone,shallow clone>>기록이 최근 기록에있는 한 내부를 병합 하면 작동합니다.
그렇지 않으면 관련이없는 기록을 병합하는 것과 같으며 큰 충돌이 발생할 수 있습니다.
이러한 제한으로 인해 이러한 리포지토리가 병합 기반 워크 플로에 사용하기에 적합하지 않을 수 있습니다.

2020 업데이트 :

• git 2.11.1은 git fetch --shallow-exclude=모든 기록을 가져 오는 것을 방지하는 옵션 을 도입했습니다.
• git 2.11.1은 git fetch --shallow-since=오래된 커밋을 가져 오는 것을 방지하는 옵션 을 도입했습니다 .

얕은 클론 업데이트 프로세스에 대한 자세한 내용은 " git 얕은 클론을 업데이트하는 방법? " 을 참조하십시오 .

리차드 마이클의 코멘트 :

역사를 채우는 방법 : git pull --unshallow

그리고 Olle Härstedt 는 다음 과 같이 주석을 추가합니다 .

히스토리의 일부 를 백업하려면 다음을 수행하십시오 git fetch --depth=100.

비슷한 질문에 대한 답변 인 why-cant-i-push-from-a-shallow-clone 과 git list의 최근 스레드에 대한 링크를 참조하십시오.

궁극적으로 '깊이'측정은 (a) 헤드 또는 (b) 복제 / 페치 된 커밋 또는 (c) 다른 것이 아니라 개별 HEAD에서 측정하기 때문에 repos간에 일관성이 없습니다. 당신은 염두에 두었습니다.

하드 비트는 유스 케이스 권리 (즉, 일관된)를 얻으므로 분산되어 아마도 다양한 저장소가 여전히 행복하게 작동합니다.

그것은 모습을 않는 checkout --orphan권리 '셋업'단계이지만, 여전히 "복제"단계에서 (즉, 간단한 이해 한 라인 명령) 안내 깨끗한 부족하다. 오히려 init저장소에 있어야 하고 remote추적 지점을 설정하고 (한 지점 만 원하십니까?) fetch그 단일 지점은 실수 할 가능성이 더 큽니다.

편집 : '복제'단계에 대해서는 이 답변을 참조하십시오