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

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

그--depth 1옵션:

기록이 지정된 리비전 수만큼 잘린 얕은 복제본을 만듭니다.얕은 저장소에는 여러 가지 제한이 있지만(복제하거나 가져올 수 없으며, 저장소에서 밀어넣거나 밀어넣을 수도 없음), 오래된 대형 프로젝트의 최근 기록에만 관심이 있고 패치로 수정 사항을 보내려는 경우에는 적합합니다.

하지만 저는 얕은 복제를 성공적으로 수행했고, 몇 가지 변경 사항을 적용했으며, 이러한 변경 사항을 (베어 복제) 원점으로 되돌렸습니다.

저는 이해가 됩니다. 제 말은 왜 안 된다는 거죠?복제된 HEAD가 출처에서 확인되고 여기에 내 약속이 더해지면, 이유가 없어 보입니다.하지만 설명서에는 다르게 나와 있습니다.

저는 얕은 클론의 아이디어를 좋아합니다. 예를 들어, 드루팔 코어: 제가 7시부터 시작했을 때 드루팔 4에서 무슨 일이 있었는지 알 필요가 없습니다. 하지만 저는 제 발에 총을 쏘고 싶지 않습니다.

그렇다면 얕은 복제, 그 안에서 커밋을 개발하고, 원본 업데이트를 따라잡기 위해 다시 끌어오는 것이 안전할까요?

Git 1.9/2.0(2014년 1분기)에서는 이러한 제한이 제거되었습니다.
82fba2b, Nguyễn Thai Ngọc Duy()pclouds에서 참조:

이제 Git는 얕은 클론에서 또는 얕은 클론으로 데이터 전송을 지원하므로 이러한 제한은 더 이상 적용되지 않습니다.

이제 설명서의 내용은 다음과 같습니다.

--depth <depth>::

기록이 지정된 리비전 수만큼 잘린 '허름한' 복제본을 만듭니다.

이는 0d7d285, f2c681c 및 c29a7b8과 같은 커밋에서 비롯됩니다. 이 커밋은 얕은 클론에서 클론, 송신/수신 팩을 지원합니다.
이제 Smart-flock은 얕은 가져오기/클론도 지원합니다.

모든 세부 정보는 ":shallow.c "에 대한 새 커밋을 선택하는 8단계에 있습니다.

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

---

2016년 1월 업데이트: Git 2.8(Mach 2016)은 이제 최소한의 이력을 얻는 관행을 공식적으로 문서화합니다.
커밋 99487cf, 커밋 9cfde9e(2015년 12월 30일), 커밋 9cfde9e(2015년 12월 30일), 커밋 bac5874(2015년 12월 29일), 커밋 1de2e44(2015년 12월 28일)를 참조하십시오. 스미스('').
^{(Junio C Hamano에 의해 합병됨 -- -- 커밋 7e3e80a, 2016년 1월 20일)}

여기는 ""입니다.Documentation/user-manual.txt

A <<def_shallow_clone,shallow clone>>스위치를 지정하여 생성됩니다.
깊이는 나중에 스위치를 사용하여 변경하거나 전체 기록을 복원할 수 있습니다.--unshallow.

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

2020년 업데이트:

• 2 옵션 git 2.11.1 설정git fetch --shallow-exclude= 것을 하기 위해 사용합니다.
• 2 옵션 git 2.11.1 설정git fetch --shallow-since=오래된 커밋을 가져오는 것을 방지합니다.

---

얕은 복제본 업데이트 프로세스에 대한 자세한 내용은 "Git 얕은 복제본을 업데이트하는 방법"을 참조하십시오.

---

Richard Michael이 언급한 바와 같이:

기록을 다시 채우려면:

그리고 올레 하르슈테트는 논평에서 다음과 같이 덧붙입니다.

기록의 일부를 다시 채우려면: .

유사한 질문에 대한 몇 가지 답변과 Git 목록에서 최근 스레드에 대한 링크를 확인하십시오.

궁극적으로 '깊이' 측정은 (a) 머리, (b) 복제/가져온 커밋 또는 (c) 염두에 둔 다른 것이 아니라 개별 HEAD에서 측정하기 때문에 저장소 간에 일관되지 않습니다.

어려운 점은 사용 사례를 올바르게 파악하는 것(즉, 자가 일관성)이므로 분산된 다양한 저장소는 여전히 함께 사용할 수 있습니다.

그것은 정말로 그것처럼 보입니다.checkout --orphan는 올바른 '설정' 단계이지만 여전히 "복제" 단계에 대한 깨끗한(즉, 이해할 수 있는 단순한 한 줄 명령) 지침이 부족합니다.오히려 당신이 해야 할 것처럼 보입니다.init 포레, 정설을 합니다.remote분기 추적(하나의 분기만 원합니까?)을 선택한 다음fetch실수할 기회가 더 많아진 것처럼 느껴지는 그 하나의 가지.

편집: '복제' 단계는 다음 답변을 참조하십시오.

언급URL : https://stackoverflow.com/questions/6941889/is-it-safe-to-shallow-clone-with-depth-1-create-commits-and-pull-updates-aga