.git 폴더를 축소하는 방법


134

내 현재 기지의 총 크기는 약입니다. 200MB.

그러나 내 .git 폴더의 놀라운 크기는 5GB (!)입니다. 작업을 외부 서버로 푸시하므로 큰 로컬 기록이 필요하지 않습니다 ...

노트북의 공간을 확보하기 위해 .git 폴더를 어떻게 축소 할 수 있습니까? 30 일이 지난 모든 변경 사항을 삭제할 수 있습니까?

어떤 도움을 주셔서 감사합니다 :)


2
의 출력을 게시 할 수 있습니까 git count-objects -v?
CB Bailey

답변:


113

30 일이 지난 모든 변경 사항을 삭제해서는 안됩니다 (어쨌든 git 악용 가능성은 있지만 실제로 권장하지는 않습니다).

를 호출하면 git gc --aggressive --prune리포지토리에서 가비지 수집을 수행하고 오래된 개체를 제거합니다. 자주 바뀌는 바이너리 파일 (아카이브, 이미지, 실행 파일)이 많이 있습니까? 그것들은 일반적으로 거대한 .git 폴더로 이어집니다 (git는 각 개정판의 스냅 샷을 저장하고 바이너리 파일은 심하게 압축합니다)


32
실제로 git gc --aggressive는 나쁜 습관으로 간주됩니다. 를 사용하는 것이 좋습니다 git repack -a -d --depth=250 --window=250.
Artefact2

18
@knittl : 절대적으로. Linus 자신의 메시지는 다음과 같습니다. gcc.gnu.org/ml/gcc/2007-12/msg00165.html
Artefact2

3
@ artefact2 : 링크 주셔서 감사합니다! 나는 그것을 읽었고 linus는-공격적 인 델타는 재사용하지 않을 것이라고 지적했다.이 질문에는 존재하지 않는 것으로 보인다. 재 포장 방법은 실제로 훨씬 더 오래 걸립니다. git gc --aggressive창 크기 250 (참조 맨 페이지) 및 깊이 250 (소스 코드 참조)으로 리팩 호출 --aggressive는 -f스위치를 추가하여 이전의 모든 델타 작업을 버리고 다시 실행합니다 (링크에서 언급 한 바와 같이)
knittl

1
방금 git-remote-hg를 사용하여 hg.nginx.org/nginx repo (RELEASE-1.4.0이 tip)를 확인했는데 약 100MB의 저장소가 생성되었습니다. 를 사용하면 git gc --aggressive --prune이것을 19MB로 줄였습니다.
Lekensteyn

15
@ Artefact2 귀하의 진술이 오래되었습니다 : 그 게시물이 몇 살인지 기록하십시오. 실제로, 게시 된 바로 그 날, 메일 링리스트에 대한 논의로 인해 다음과 같은 커밋이 발생했습니다. [..] 따라서 패킹 매개 변수는 요즘 어느 방법에서나 동일합니다. . --prune이후 기본값 v1.5.5-rc0되었으므로 필요하지 않습니다 ( 2008 년 3 월 25ee973 커밋 ).
Lekensteyn

68

git Linus 제작자가 git repo를 줄이는 방법에 대해 말한 내용은 다음과 같습니다 .

"git gc --aggressive"와 동일하지만 * 적절하게 * 수행 된 것은 다음과 같은 작업을 수행하는 것입니다.

   git repack -a -d --depth=250 --window=250

그 깊이는 델타 체인이 얼마나 깊을 지에 관한 것입니다 (오래된 역사를 위해 더 길게 만듭니다-공간 오버 헤드 가치가 있음). 창은 각 델타 후보가 스캔하기를 원하는 객체 창이 얼마나 큰지에 관한 것입니다.

그리고 여기에 "-f"플래그 ( "이전 델타를 모두 삭제")를 추가하는 것이 좋습니다. 실제로이 플래그가 실제로 좋은 후보를 찾도록하기 위해 노력하고 있기 때문입니다.

출처 : http://gcc.gnu.org/ml/gcc/2007-12/msg00165.html

내 저장소에 고아 이진 데이터가 제거됩니까? "git repack"은 repo에 체크인 한 후 삭제 한 이미지 또는 이진 데이터를 제거하지 않습니다. 리포지토리에서 이러한 종류의 데이터를 영구적으로 삭제하려면 기록을 다시 작성해야합니다. 일반적인 예로는 실수로 git에서 암호를 체크인했을 때입니다. 다시 돌아가서 일부 파일을 삭제할 수 있지만 그때부터 지금까지 기록을 다시 작성 한 다음 새 저장소를 강제로 원점으로 푸시해야합니다.


나를 위해 .git 폴더는 약 1.5G입니다. 나는 이것을 시도했지만 후속 오류가 발생했습니다. fatal: Out of memory, malloc failed (tried to allocate 39763130 bytes)
Miron

2
repack로컬로 실행 한 후 커밋 및 푸시를 수행하면 축소도 원격으로 수행됩니까?
Timo

@David Dehghan : 야 프로젝트 디렉토리에서 시도했지만 .git 폴더의 크기는 변경되지 않았습니다. 이것이 예상됩니까, 아니면 변경 사항을 보려면 푸시해야합니까? (git에 익숙하지 않은 죄송합니다.) repo에 이미지 / gif가 있고 해당 이미지의 여러 번 다른 버전을 커밋했으며 .git 크기가 증가했다고 가정합니다.
giorgim

안타깝게도 이제 이전 바이너리 버전을 정리하는 방법입니다. 그렇게하려면 실제로 복잡한 기록을 다시 작성해야합니다. 여기에 대한 몇 가지 리드는 다음과 같습니다 docs.microsoft.com/en-us/azure/devops/articles/...
데이비드 Dehghan

22

나는 이것을 시도했지만 내 저장소는 여전히 매우 컸다. 문제는 실수로 생성 된 일부 큰 파일을 체크인했다는 것입니다. 일부 검색 후 큰 생성 파일을 쉽게 삭제할 수있는 훌륭한 자습서를 찾았습니다. 이 튜토리얼을 통해 저장소를 60MB에서 <1MB로 축소 할 수있었습니다.

Steve Lorek, Git 리포지토리를 축소하는 방법


4
링크 썩음의 경우 보관 된 버전다음과 같습니다 . 이 답변은 .exe 및 .zip 파일이 커밋 된
리포지토리에 유용

9

5GB 대 200MB는 이상합니다. 실행 해보십시오 git gc.

그러나 저장소를 모듈로 분할하지 않으면 .git디렉토리 의 크기를 줄일 수 없습니다 .

자식 저장소의 각 복제본은 서버 역할을 할 수있는 본격적인 저장소입니다. 이것이 분산 버전 제어의 기본 원칙입니다.


3

버전 기록보다 동기화 메커니즘으로 git을 더 많이 사용하고 있습니다. 따라서이 문제에 대한 나의 해결책은 현재의 모든 소스가 만족스러운 상태인지 확인한 다음 .git을 삭제하고 repos를 다시 초기화하는 것입니다. 디스크 공간 문제가 해결되었습니다. :-) History gone :-( 레포가 작은 USB 키에 있기 때문에이 작업을 수행합니다. 전체 기록을 원하지 않거나 필요로하지 않습니다. 기록을 잘라내는 방법이 있다면 사용합니다.

내 기록을 유지하는 데 관심이 있다면 현재 저장소를 보관합니다. 나중에 원래 저장소를 복제하고 새 저장소의 모든 변경 사항을 복사 할 수있었습니다 (이름을 바꾸거나 삭제하지 않은 것으로 가정합니다). 그런 다음 새 리포지토리의 모든 변경 내용을 이전 리포지토리의 단일 커밋으로 나타내는 하나의 큰 커밋을 만듭니다. 히스토리를 병합 할 수 있습니까? 아마도 내가 지점을 사용하고 필요없는 객체를 삭제했다면. (저는 git internals에 대해 충분히 알지 못합니다.)


1
대신이 사용 사례에 Dropbox를 사용할 수 있습니다. 나는 몇 년 동안했다.
Jonny

0

위의 방법을 시도했지만 내 경우에는 아무것도 작동하지 않았습니다 (git push 동안 실수로 git 프로세스를 종료 한 경우). 그래서 repo를 삭제하고 다시 복제해야했으며 이제 .git 폴더의 크기는 정상입니다.


디스크가 가득 찼기 때문에 (.git 폴더가 90GB 이상이므로) 동일한 솔루션을 사용해야했기 때문에 리팩이나 git gc조차 실행할 수 없었습니다!
Fl4v
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.