git-gc를 얼마나 자주 사용해야합니까?

git-gc를 얼마나 자주 사용해야합니까?

매뉴얼 페이지는 단순히 말합니다 :

디스크 공간을 효율적으로 사용하고 운영 성능을 유지하려면 각 저장소 내에서이 작업을 정기적으로 실행하는 것이 좋습니다.

gc 시간인지 알아 내기 위해 객체 수를 얻는 명령이 있습니까?

그것은 저장소가 얼마나 많이 사용되는지에 달려 있습니다. 한 명의 사용자가 하루에 한 번 체크인하고 일주일에 한 번 지점 / 병합 / 기타 작업을 수행하면 1 년에 한 번 이상 실행할 필요가 없습니다.

하루에 2-3 번씩 체크인하는 수십 개의 프로젝트를 작업하는 수십 명의 개발자와 함께 매일 밤 실행하고 싶을 수도 있습니다.

그러나 필요한 것보다 더 자주 실행하는 것은 아프지 않습니다.

내가 한 것은 지금 실행 한 다음 일주일 후 디스크 사용률을 측정하고 다시 실행 한 다음 디스크 사용률을 다시 측정하는 것입니다. 크기가 5 % 감소하면 일주일에 한 번 실행하십시오. 더 많이 떨어지면 더 자주 실행하십시오. 덜 떨어지면 덜 자주 실행하십시오.

저장소를 가비지 수집하는 단점은 가비지가 수집된다는 것입니다. 우리 모두 컴퓨터 사용자로 알고 있듯이, 현재 쓰레기로 간주되는 파일은 앞으로 3 일 동안 매우 가치있는 것으로 판명 될 수 있습니다. git이 대부분의 잔해물을 유지한다는 사실은 베이컨을 여러 번 절약했습니다. 매달린 커밋을 모두 찾아서 우연히 통조림으로 만든 많은 작업을 복구했습니다.

따라서 개인 복제본에서 너무 깔끔하지 마십시오. 거의 필요하지 않습니다.

OTOH, 데이터 복구 성의 가치는 예를 들어 주로 리모콘으로 사용되는 저장소에 의문의 여지가 있습니다. 모든 개발자가 밀거나 당기는 장소. GC 실행을 시작하고 자주 재 포장하는 것이 합리적 일 수 있습니다.

최신 버전의 git은 필요할 때 자동으로 gc를 실행하므로 아무것도 할 필요가 없습니다. man git-gc (1) 의 옵션 섹션을 참조하십시오 . "일부 git 명령은 많은 느슨한 객체를 생성 할 수있는 작업을 수행 한 후 git gc --auto를 실행합니다."

당신이 사용하는 경우 힘내 - GUI를 , 그것은 당신을 알려줍니다 당신이 걱정해야 할 때 :

This repository currently has approximately 1500 loose objects.

다음 명령은 비슷한 숫자를 가져옵니다.

$ git count-objects

소스에서 제외하고 git-gui는 실제로 .git/objects폴더 에서 무언가를 계산 하고 아마도 근사치를 가져올 것입니다 ( tcl정확히 읽을 수 는 없습니다 !).

어쨌든 약 300 개의 느슨한 물체를 기준으로 경고를 표시 하는 것 같습니다 .

자고있을 때 매일 밤 (오후?)에 운영되는 크론 작업에 버리십시오.

큰 체크 아웃을 한 후에 git gc를 사용하고 많은 새로운 객체가 있습니다. 공간을 절약 할 수 있습니다. 예를 들어 git-svn을 사용하여 큰 SVN 프로젝트를 체크 아웃하고 git gc를 수행하면 일반적으로 많은 공간을 절약합니다.

새로운 (Git 2.0 Q2 2014) 설정으로 중단없이 할 수 있습니다 gc.autodetach.

참조 4c4ac4d 커밋 과 9f673f9 커밋 ( pclouds 일명 응우 엔 타이 응옥 두이을 ) :

gc --auto시간이 걸리고 사용자를 일시적으로 차단할 수 있습니다.
이를 지원하는 시스템에서 백그라운드로 실행하십시오.
백그라운드에서 실행하면서 잃어버린 유일한 것은 출력물입니다. 그러나 gc output실제로 흥미롭지는 않습니다.
을 변경하여 포 그라운드로 유지할 수 있습니다 gc.autodetach.

2.0 릴리스 이후 버그가 발생했습니다 : git 2.7 (Q4 2015)은 오류 메시지를 잃지 않도록합니다 .
참조 329e6e8 커밋 에 의해 (2015년 9월 19일를) 응웬 타이 응옥 두이 ( pclouds) .
^{(가 합병 - Junio C 하마노 gitster- 에 076c827 커밋 2015 15 시월)}

gc: 데몬에서 로그를 저장 gc --auto하고 다음에 인쇄

하지만 9f673f9 커밋 ( gc: 실행하기위한 설정 옵션을 --auto배경 - 2014년 2월 8일하는) '에 대한 몇 가지 불만을 줄이는 데 도움이 gc --auto터미널을 독차지'를, 그것은 문제의 또 다른 세트를 작성합니다.

이 세트의 최신은 데몬 화 결과로 stderr닫히고 모든 경고가 유실됩니다. 이 경고 cmd_gc()는 사용자에게 " gc --auto"반복 실행 을 피하는 방법을 알려주기 때문에 특히 중요합니다 .
stderr가 닫혀 있기 때문에 사용자는 모르고 자연스럽게 gc --autoCPU 낭비 에 대해 불평 합니다.

데몬 화가에 gc저장 stderr됩니다 $GIT_DIR/gc.log. 사용자가 제거 할 때까지
다음 gc --auto은 실행 및 gc.log인쇄 되지 않습니다gc.log .

이 인용문은 다음과 같습니다. 힘내 버전 관리

Git은 가비지 수집을 자동으로 실행합니다 .

• 리포지토리에 느슨한 개체가 너무 많은 경우

• 원격 저장소에 대한 푸시가 발생하는 경우

• 느슨한 객체가 많이 생길 수있는 명령 후

• git reflog와 같은 일부 명령이 명시 적으로 만료되면 요청

마지막으로 git gc 명령을 사용하여 명시 적으로 요청하면 가비지 수집이 발생합니다. 하지만 언제 그래야합니까? 이 질문에 대한 확실한 대답은 없지만 좋은 조언과 모범 사례가 있습니다.

몇 가지 상황에서 git gc를 수동으로 실행하는 것을 고려해야합니다.

• 방금 git filter-branch를 완료 한 경우. filter-branch는 많은 커밋을 다시 작성하고 새로운 커밋을 소개하며 결과에 만족할 때 제거해야하는 ref에 기존 커밋을 남겨 둡니다. 사용하지 않는 모든 객체 (그냥 참조하는 객체를 방금 삭제했기 때문에 더 이상 참조되지 않음)는 가비지 수집을 통해 제거해야합니다.

• 몇 가지 명령을 수행하면 느슨한 객체가 많이 발생할 수 있습니다. 예를 들어 이것은 큰 재베이스 노력 일 수 있습니다.

반대로, 가비지 수집에 대해 언제주의해야합니까?

• 복구 할 수있는 고아 심판이있는 경우

• git rerere의 맥락에서 해상도를 영원히 저장할 필요는 없습니다.

• 태그와 브랜치만으로 Git이 커밋을 영구적으로 유지하기에 충분

• FETCH_HEAD 검색 컨텍스트 (git fetch를 통한 URL 직접 검색)는 가비지 수집에 즉시 영향을 받기 때문에 검색합니다.

큰 커밋을 할 때, 무엇보다 저장소에서 더 많은 파일을 제거 할 때 사용합니다 .. 커밋이 더 빠릅니다.

(가비지 수집)은 자주 사용되는 몇 가지 명령에서 자동으로 실행 git gc되므로 자주 사용하지 않아도됩니다 git gc.

git pull
git merge
git rebase
git commit

출처 : git gc 모범 사례 및 FAQ