은 내가 주제와에있는 모든 개체를 제거하려는git 브랜치를 정말로 삭제하는 (즉, 모든 객체/커밋을 제거하는) 방법은 무엇입니까?
A---B---C topic
/
D---E---F---G master <--
같은 자식의 나무가 있습니다.
내가 주제의 SHA ID를 참고 한 후 입력 :
git branch -D topic
git gc # <-- I also tried prune here...
git checkout -b temp <SHA1 ID of topic>
을 마지막 명령 후 나는 오류 ("비 존재 오브젝트 ID ..."또는 somth 뭔가를 얻을 것으로 예상처럼.). 그러나 오류가없고 gitk는 위와 같은 트리 구조를 보여 줍니까?
내가 누락 된 부분 - gc/prune이 연결할 수없는 모든 개체를 삭제해야한다고 생각 했습니까?
참고 사항 2010 년 5 월 참고 : mentioned by Jakub으로, 분기가 병합 된 경우 여전히 주제에 도달 할 수 있습니다.
여기서는 병합이 없다고 가정 해 보겠습니다.
그런 다음이 SO question에서 mentioned in the ProGit book 상세한 같이
git gc --prune=now
이 충분해야 (직접 git prune를 호출해야합니다). git count-objects -v으로 제어 할 수 있습니다.
2012 년 4 월 편집 : Duke의 answer (단, git repack 제외)에 설명 된대로 추가 단계가 필요할 수 있음을 코멘트에있는 maxschlepzig에서 확인합니다. 그래서 대신 git gc --prune now의
:
git reflog expire --expire=now --all
git gc --aggressive --prune=now
"도달 할 수 없음"은 실제로 여기에 암시하는 것보다 훨씬 강력합니다. 'git-gc '에 관한 한, reflog에서 도달 할 수 있다면 객체에 도달 할 수 있고 reflog는 만료되기까지 오랜 시간이 걸린다. 예를 들어 브랜치를 마스터에 병합하고, 잘못되었다는 것을 알았고, 마스터를 이전 위치로 재설정 할 수 있으며, reflog 항목이 만료 될 때까지 커밋을 도달 가능으로 간주 할 수 있습니다 (기본 90 일). – Cascabel
또한, 아마 말할 것도없이'--prune = now'를 사용하여 매우 신중해야합니다. 다른 중요한 커밋이 사라 졌음을 알기 직후에 깨닫는 것은 끔찍할 것입니다. – Cascabel
고마워, 너 락! :) – Alan
는 그냥 GC의 자두는 종종 REPO에 추가 개체를 제거하는 것만으로는 충분하지 않습니다. reflog에서 커밋이 여전히 참조되는 경우 해당 개체가 도달 할 수 없으므로 제거를 위해 익숙하지 않습니다.
git reflog expire --expire=now --all
git gc --aggressive --prune=now
git repack -a -d -l
이 당신의 repo의 역사에 약간 수정을가합니다, 잘 현재의 어려움을 다른 사람들이 당신이 날려 가지에 의존하는 수 있습니다 경우 :
여기에 나를 위해 일한거야.
실제로 저장소의 크기 차이를 확인하려면 저장소를 다시 복제해야 할 수 있습니다.
흥미로운 의견. +1 – VonC
git reflog expire --expire = now --all'을 사용해야했습니다. 추가 된 "만료"에 유의하십시오. –
테스트 한 결과 재 포장 단계가 필요하지 않았습니다. – maxschlepzig
VonC의 답변으로 문제의 사실을 설명합니다. "철학적 인"이유를 알고 싶다면 git이 우연히 아무 것도 삭제하지 못하도록 아주 열심히 시도하는 것입니다. 'git gc' 자체는 정리/재 포장 작업을위한 것입니다. 최근 작업을 삭제할 수 있도록하려면 좀 더 강하게 말해야합니다. – Cascabel