누구든지 파일 수와 파일 크기에 대한 Git 제한이 무엇인지 알고 있습니까?
답변:
Linus가 보낸 이 메시지는 다른 한계를 가지고 당신을 도울 수 있습니다
[...] CVS, 즉 "한 번에 하나의 파일"모델을 지향합니다.
백만 개의 파일을 가질 수 있으며 그중 몇 개만 체크 아웃 하면 다른 999,995 파일의 영향을 볼 수 없습니다 .
힘내는 근본적으로 실제로 전체 레포보다 적지 않습니다. 일을 조금만 제한하더라도 (즉, 일부만 체크 아웃하거나, 역사가 조금 되돌아가도), git은 여전히 모든 것에 관심을 갖고 지식을 가지고 다니게됩니다.
따라서 git은 모든 것을 하나의 거대한 저장소 로 보도록 강요하면 정말 심하게 확장 됩니다. 나는 우리가 아마도 그것을 개선 할 수는 있지만 부분이 실제로 고칠 수 있다고 생각하지 않습니다.
그리고 네, "큰 파일"문제가 있습니다. 나는 거대한 파일에 대해 어떻게 해야할지 모르겠다. 우리는 그들을 빨아 먹는다.
다른 답변 에서 더 많은 것을보십시오 : Git의 한계는 각 저장소가 " 일관된 파일 세트 ", "모든 시스템"자체를 나타내야한다는 것입니다 ( "저장소의 일부"를 태그 할 수는 없습니다).
시스템이 자율적이지만 상호 의존적 인 부품으로 만들어진 경우 하위 모듈 을 사용해야합니다 .
Talljoe의 답변 에서 알 수 있듯이 한도는 시스템 하나 (대수의 파일 수) 일 수 있지만 Git의 특성을 이해하면 (SHA-1 키로 표시되는 데이터 일관성에 대해) 진정한 "제한"을 알 수 있습니다 A는 사용 즉, 당신이 저장하려고해서는 안 : 한 모든 것을 당신은 항상 얻을 또는 태그 모든 것을 다시 준비하지 않는 한, 힘내 저장소에이. 일부 큰 프로젝트의 경우에는 의미가 없습니다.
git limit에 대한 자세한 내용은 " 큰 파일을 가진 git "
( git-lfs : git repo 외부에 큰 파일을 저장하는 솔루션을 참조하십시오 . GitHub, 2015 년 4 월)
git repo를 제한하는 세 가지 문제 :
최신 스레드 (2015 년 2 월) 는 Git 리포지토리의 제한 요소를 보여줍니다 .
중앙 서버에서 몇 개의 동시 복제본이 다른 사용자의 다른 동시 작업 속도를 늦출 수 있습니까?
복제시 서버에는 잠금이 없으므로 이론 복제는 다른 작업에 영향을 미치지 않습니다. 복제는 많은 양의 메모리를 사용할 수 있습니다 (연결 가능성 비트 맵 기능을 설정하지 않은 경우 많은 CPU를 사용해야 함).
'
git pull'가 느려 집니까?서버 측을 제외하면 트리의 크기가 주요 요인 이지만 25k 파일은 괜찮습니다 (리눅스에는 48k 파일).
'
git push'?이것은 레포의 역사가 얼마나 깊은 지 또는 나무가 얼마나 넓은 지에 영향을받지 않으므로 빨리해야합니다.
아 심판의 수는 모두에 영향을 미칠 수
git-push및git-pull.
스테판은이 분야에서 나보다 잘 알고 있다고 생각합니다.'
git commit'? ( 참조 3 에서 느리게 나열되어 있습니다.) 'git status'? (보이지 않지만 참조 3에서 다시 느리게하십시오.)
(또한git-add)다시, 당신의 나무의 크기. 귀하의 레포 크기에 대해서는 걱정할 필요가 없습니다.
일부 작업은 일상적인 것처럼 보이지 않을 수 있지만 웹 프런트 엔드에서 GitLab / Stash / GitHub 등으로 자주 호출되는 경우 병목 현상이 발생할 수 있습니다. (예를 들어, '
git branch --contains'는 많은 수의 분기에 의해 크게 부정적인 영향을받는 것으로 보입니다.)
git-blame파일을 많이 수정하면 속도가 느려질 수 있습니다.
실제 제한은 없습니다. 모든 것이 160 비트 이름으로 명명됩니다. 파일의 크기는 64 비트 숫자로 표현할 수 있어야하므로 실제 제한도 없습니다.
그러나 실제적인 한계가 있습니다. 880,000 개 이상의 파일을 가진 ~ 8GB의 저장소가 있으며 git gc는 시간이 걸립니다. 작업 트리는 다소 커서 전체 작업 디렉토리를 검사하는 작업에는 시간이 오래 걸립니다. 이 저장소는 데이터 저장에만 사용되므로이를 처리하는 자동화 된 도구 일뿐입니다. 리포지토리에서 변경 내용을 가져 오는 것이 동일한 데이터를 재 동기화하는 것보다 훨씬 빠릅니다.
%find . -type f | wc -l
791887
%time git add .
git add . 6.48s user 13.53s system 55% cpu 36.121 total
%time git status
# On branch master
nothing to commit (working directory clean)
git status 0.00s user 0.01s system 0% cpu 47.169 total
%du -sh .
29G .
%cd .git
%du -sh .
7.9G .
.git디렉토리 보다 더 클 수 있습니까? 내 순진한 가정 .git에는 작업 디렉토리의 사본과 기록이 포함되어 있으므로 더 커야한다는 것입니다. 누구 든지이 크기가 어떻게 관련되어 있는지 이해하는 리소스를 알려 줄 수 있습니까?
.git디렉토리 의 내용 이 압축되었습니다. 따라서 커밋이 비교적 적은 리포지토리는 압축되지 않은 작업 디렉터리보다 압축 된 기록이 작을 수 있습니다. 내 경험에 따르면 실제로 C ++ 코드를 사용하면 전체 기록이 일반적으로 작업 디렉토리와 거의 같은 크기입니다.
2012 년 2 월, 거대한 테스트 저장소에서 Git을 테스트하는 페이스 북 소프트웨어 엔지니어 Joshua Redstone 의 Git 메일 링리스트 에는 매우 흥미로운 스레드 가있었습니다 .
테스트 저장소에는 4 백만 개의 커밋, 선형 기록 및 약 130 만 개의 파일이 있습니다.
실행 된 테스트에 따르면 이러한 리포지토리의 Git을 사용할 수없는 것으로 나타 났지만 (차가운 작업은 몇 분 동안 지속될 수 있음) 향후에 변경 될 수 있습니다. 기본적으로 성능은 stat()커널 FS 모듈에 대한 호출 수에 의해 불이익을 받으므로 리포지토리의 파일 수와 FS 캐싱 효율성에 따라 달라집니다. 자세한 내용은 이 요지 를 참조하십시오 .
2018-04-20 현재 Windows 용 Git에는 특정 구현을 사용하여 파일 크기를 최대 4GB로 효과적으로 제한 하는 버그 가 있습니다 (이 버그 는 lfs에도 전파됩니다 ).
나는 이것이 repo에 많은 수의 파일 (350k +)을 저장하려고한다는 것을 알았습니다. 예, 저장하십시오. 웃어요
$ time git add .
git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total
Bitbucket 설명서 의 다음 추출 내용 은 매우 흥미 롭습니다.
DVCS 리포지토리 복제 작업을 수행 할 때 전체 리포지토리 및 모든 기록을 사용하게됩니다. 실제로 리포지토리가 500MB보다 커지면 문제가 발생할 수 있습니다.
... Bitbucket 고객의 94 %가 500MB 미만의 리포지토리를 가지고 있습니다. 리눅스 커널과 안드로이드는 900MB 미만입니다.
이 페이지에서 권장되는 솔루션은 프로젝트를 작은 조각으로 나누는 것입니다.
git은 repo에 대한 4G (32bit) 제한이 있습니다.