shallow clone의 한계점

Question

우리는 Git을 소개하고자하는 조직에서 바이너리 파일과 관련된 Git 동작과 관련된 문제가 있습니다.
우리 프로젝트에는 바이너리와 텍스트 유형 파일이 잘 혼합되어 있으며 일반적인 크기는 1GB가 될 수 있습니다. 우리의 두려움은 몇 년 후 전체 클론이 너무 커져 성능 및 디스크 공간 문제가 발생한다는 것입니다.
Git으로 마이그레이션 할 환경 중 하나는 SW가 현재 TCM이라는 시스템에 있습니다. 7-10 년 버전의 저장소의 전체 크기는 2TB입니다.
ClearCase의 또 다른 환경은 약 7-8 년 동안 약 1TB의 데이터를 보유합니다.
Git이 특히 바이너리 파일에 영향을 줄 델타에 저장하지 않으면 5 년 이상 지나면 사용자에게 우려가됩니다.
얕은 복제 기능이 이상적이었을 것입니다. 하지만 문서는 이렇게 말합니다. "얕은 저장소는 많은 제한이 있습니다 (복제하거나 가져올 수도없고 가져올 수도없고 가져올 수도 없습니다). 그러나 긴 프로젝트의 최근 기록에만 관심이 있다면 충분합니다. 기록을 수정하고 패치로 수정 사항을 보내고 싶습니다. " 얕은 클론에 대한 간단한 검사는 제대로 작동 함을 보여 주지만 작동하지 않는 사용 사례가 있다는 것을 확실히 알 수 있습니다. 따라서 문서
작동하지 않는 알려진 사용 사례 목록이 있습니까?

Answer 1

이진 파일을 전용 저장소에 저장하고 쉽게 확장 및 정리가 가능하도록 권장합니다 : Nexus과 같은 이슈 저장소.
다른 대안이있는 "How to handle a large git repository?"이 있습니다.

Git에서 모든 것을 부 자연스러운 방식으로 사용하려고 시도하면 항상 소스 컨트롤 도구 인 더 많은 문제가 발생합니다. 당신은 그것이 좋은 것을 위해 그것을 사용할 수도 있습니다.

즉, 얕은 복제는 밀어 넣기를 지원하지 않습니다 (또는 적어도 위험합니다 : "Why can't I push from a shallow clone?"참조).
읽기 전용이므로 "not understanding git shallow clone"에서 언급 한 것처럼 git archive이면 충분합니다. 업데이트 2015

:

• 실제로, 당신은 지금 단 한 번의 커밋 가져 오기 (2.5 + 힘내와) 당신이 할 수있는 "Is git clone --depth 1 (shallow clone) more useful than it makes out?"
• 를 참조 당겨/푸시에 대한 얕은 복제를 사용할 수 있습니다. "Pull a specific commit from a remote git repository"을 참조하십시오.

Answer 2

Git Annex은 "big-binary-files in/near git"문제를 아주 아름답게 해결합니다.