답변:
짧은 버전 : 그것은 그것이 말하는 것을 의미하며, 그냥 끝내면 모든 것이 잘 될 것입니다.
리포지토리 (푸시 포함)에서 느슨하게 (포장되지 않은) 객체의 수를 잠재적으로 늘릴 수있는 대부분의 작업 중에 Git이 호출합니다 git gc --auto. 느슨한 객체가 충분하면 (기본적으로 6700 이상) git repack -d -l포장 을 위해 호출 됩니다. 개별 팩이 너무 많으면 다시 포장합니다.
팩은 많은 수의 객체를 포함하는 델타 압축 단일 파일입니다. 팩에 객체를 저장하는 것이 더 효율적이지만 객체를 팩킹 (압축)하는 데 시간이 걸리므로 Git은 처음에 느슨한 객체를 생성 한 다음 자동 호출을 통해 배치로 묶습니다 git gc --auto.
Git이 재 포장을 완료하게되면 잠시 동안 이런 일이 다시 발생하지 않습니다. 특히 큰 이진 객체가 많은 경우 시간이 오래 걸릴 수 있지만 트리거하는 경우 리포지토리가 차지하는 디스크 공간을 크게 줄일 수 있다는 신호입니다. 실제로 원하지 않는 경우 config 매개 변수를 변경할 수 있습니다 gc.auto. 6700보다 훨씬 큰 값으로 늘리면 덜 자주 발생하지만 더 오래 걸립니다. 줄이면 계속해서 현재 재 포장 작업을 수행해야하지만 이후에는 더 자주 발생하고 더 빨리 완료됩니다. 0으로 설정하면 자동 리 패킹이 비활성화됩니다.
자세한 내용은 man git-gc(아래 --auto) 및 man git-config(아래 gc.auto)를 참조하십시오.
fatal: Out of memory, malloc failed (tried to allocate 79610689 bytes) error: failed to run repack- 이것은 내가 한 자식의 repo에 우리의 전체 코드베이스를 고집 무엇을 얻을 수 있습니다. 내가 응용 프로그램을 죽이고 "수동으로"강제로 재 포장 할 것 같아요
Jefroni가 자동 포장을 완료하는 데 시간이 필요한 경우도 있지만 OP에 설명 된대로 자동 포장 메시지가 며칠 동안 지속되면 이 질문에 설명 된대로 git의 정리에 매달려있는 개체가 누락 될 가능성이 높습니다 .
매달려있는 개체가 자동 포장에 대한 진행중인 메시지를 트리거하는지 확인하려면을 실행 해보십시오 git fsck. 매달려있는 커밋 목록이 길면 정리할 수 있습니다.
git gc --prune=now
보통 한 번 잡아 당긴 후 자동 포장 메시지가 사라지지 않을 때 2-3 개월마다 내 저장소 에서이 작업을 실행해야합니다.
git pull며칠 동안을 할 때마다 메시지 fsck를 받았으며 실제로 많은 커밋을 보여주었습니다.
한 프로젝트에서 비활성화하려면 :
cd your_project_dir
git config gc.auto 0
전역 적으로 비활성화하려면 :
git config --global gc.auto 0
바라건대, 그 git gc --auto단계는 이제 (git 2.0.1, 2014 년 6 월 25 일) 더 효율적입니다.
참조 62aad18을 투입 하여 (응웬 타이 응옥 두이 pclouds)
gc --auto: 백그라운드에서 심판을 잠그지 마십시오.9f673f9 (
gc: 백그라운드에서 --auto를 실행하기위한 구성 옵션 -2014-02-08 , Git 2.0.0)은gc --auto사용자의 대기 시간을 줄이기 위해 백그라운드 에 " "를 넣 습니다.
가비지 수집의 일부는 팩 참조 및 정리 참조 로그입니다. 이것들은 일부 심판을 잠 가야하며 같은 심판을 잠그려고하는 다른 프로세스를 중단시킬 수 있습니다.경우
gc --auto스크립트의 중간에 발사되어, 백그라운드에서 GC의 유지 잠금 전에 결코 일어날 수있는 스크립트, 실패 할 수 9f673f9을 .병렬 참조 업데이트를 중지하려면 전경에서
pack-refs"reflog --prune"를 계속 실행하십시오 . 나머지 백그라운드 작업 (재 포장, 제거 및 다시 실행)은 git 프로세스 실행에 영향을 미치지 않아야합니다.
그리고 Git 2.22 (2019 년 2 분기)는 더욱 최적화되었습니다git gc .