Git 커밋 하나는 디스크를 얼마나 차지할까요?

AI 요약

Git 커밋 크기는 변경된 바이트 수만으로 정해지지 않습니다. Git은 객체를 zlib으로 압축해 저장하고, 나중에는 여러 객체 사이의 중복을 줄이는 팩파일(packfile)도 만듭니다. 이 글은 팩파일을 생성하지 않은 저장소에서 커밋 전후 .git 크기를 비교해 실제 저장 공간을 살펴봅니다.

작은 변경에도 객체와 트리 비용이 붙습니다

빈 저장소의 .git 디렉터리는 64,828바이트였습니다. 여기에 5개 디렉터리, 총 250개의 작은 파일을 커밋하자 47,640바이트가 추가됐습니다. 파일 하나를 바꿔 약 3바이트를 변경한 뒤에는 17,145바이트가 더 늘었습니다. 저장소의 파일 수와 디렉터리 구조에 따라 작은 변경에도 여러 객체가 필요하기 때문입니다.

실험에서 파일 하나만 있는 저장소는 커밋 하나에 8,709바이트가 늘었습니다. 파일이 50개 든 디렉터리에서 파일 하나를 바꾼 커밋은 4개의 객체를 만들었습니다. 변경 파일 내용 객체 외에도 커밋 객체와 변경 디렉터리, 루트 디렉터리를 나타내는 트리 객체가 생겼습니다. 작성자는 각 객체를 git show로 확인해 종류와 내용을 살폈습니다.

큰 파일은 압축률에 따라 크기가 달라집니다

583,840바이트 바이너리 파일을 추가한 커밋은 297,873바이트를 차지했습니다. 16,415,223바이트짜리 텍스트 소스 파일은 1,622,188바이트만 추가됐습니다. 텍스트의 반복성이 높아 압축 효과가 컸습니다. 따라서 커밋 크기는 바뀐 파일의 원본 크기와 같지 않으며, 파일 내용의 압축 가능성에 따라 달라집니다.

이 수치는 팩파일을 만들지 않은 실험 결과입니다. 실제 저장소에서는 팩파일이 객체 사이 중복을 제거해 공간을 더 아낄 수 있습니다. 작은 커밋은 객체와 트리 구조의 비용이 변경 내용보다 커질 수 있고, 큰 변경은 파일 내용의 압축률이 저장 크기에 더 큰 영향을 줍니다.

원문: ratfactor.com / 번역·요약: Trawling