git저장소가 너무 커지는 것을 방지하려면 때로는 git gc저장소 위에서 실행해야 합니다. 하지만 여기에는 몇 가지 단점이 있습니다. 특히 메모리를 많이 소모합니다. 대체 솔루션은 저장소를 복제하고 원본 복사본을 복제본으로 바꾸는 것 같습니다. (이러한 저장소는 서버에서 호스팅되므로 여기에는 작업 복사본이 없습니다.) 이로 인해 I/O가 더 많아지지만 RAM을 덜 사용할 수 있습니다.
나는 이것이 동일한 효과를 가지지 않을 수도 있다고 생각 git gc하지만 어떻게 되는지는 잘 모르겠습니다. 질문은 다음과 같습니다.git gc베어 저장소에서 실행하는 것과 를 실행하고 git clone저장소를 삭제하고 복제본으로 바꾸는 것의 차이점은 무엇입니까?
답변1
많은 차이점이 있습니다.
첫째, 삭제 및 복제를 위해 저장소 복사본이 일부 원격 복사본과 완전히 동기화되어 더 잘 압축되었지만 동등한 저장소가 새 복제본으로 생성될 수 있다고 가정해야 합니다. 저장소를 동기화할 필요가 없고 로컬 복사본에 유지하려는 변경 사항이나 분기가 있을 수 있기 때문에 이런 일은 거의 발생하지 않습니다(네이키드인 경우에도). 삭제를 수행한 후 복제하면 이 데이터가 모두 손실되지만 git gca.
둘째, 서버가 본질적으로 복제본의 델타가 좋은 좋은 패키지를 생성할 것이라고 가정할 수 없습니다. 대부분의 Git 서버는 더 나은 설정을 사용하여 정기적으로 데이터를 패키징하는 데 더 많은 시간을 소비하지만 개체를 동적으로 패키징해야 하는 요청을 처리합니다. 이러한 설정은 여러 패키지와 여러 푸시된 데이터의 데이터를 결합해야 하기 때문에 데이터를 더 빠르게 생성할 수 있지만 패키징의 효율성은 떨어집니다. 따라서 스스로 정기적으로 다시 포장하면 더 나은 결과를 얻을 수 있으며 때로는 극적으로 나타날 수도 있습니다.
셋째, git gc중단 없이 내부에서 수행할 수 있는 반면 복제 및 교체는 Unix에서 원자적으로 수행할 수 없습니다(심볼릭 링크를 사용하지 않는 한). git gc필요에 따라 이 작업을 자동으로 수행할 수도 있지만 복제 및 교체는 수행할 수 없습니다.
넷째, 잘못된 푸시 또는 기타 오류로부터 복구하기 위해 참조 로그를 사용하는 기능에 의존하는 경우 복제 및 교체 시 git gc.
다섯째, 네트워크 연결에 따라 git gc새 복사본을 복제하는 것보다 그냥 실행하는 것이 더 빠를 수도 있습니다. 두 번째 지점에서 언급한 이유로 인해 리포지토리가 원격으로 패키징되는 방식에 따라 복제 및 교체하려는 것보다 더 많은 데이터를 전송하게 될 수 있습니다.
일반적으로 다시 패키징하는 대신 복제 및 교체를 사용하는 사람은 없습니다. 실제로 매우 큰 리포지토리를 가진 사람들은 더 나은 성능을 위해 항상 다시 복제하는 대신 자동으로 가져오고 선제적으로 패키징하는 경향이 있습니다.