10.4 Mechanizmy wewnętrzne w Git - Spakowane pliki (packfiles)

Spójrzmy na obiekty które znajdują się w testowym repozytorium Gita. W tej chwili, masz 11 obiektów – 4 blob, 3 tree, 3 commit i 1 tag:

Git kompresuje zawartość tych plików za pomocą biblioteki zlib, a Ty nie masz dużej ilości danych, więc te pliki łącznie zajmują tylko 925 bajtów. Dodajmy trochę większych plików do repozytorium, aby pokazać bardzo ciekawą funkcję Gita. Dodaj plik repo.rb z biblioteki Grit na której wcześniej pracowaliśmy – ma on około 12 tysięcy znaków:

Jak spojrzysz na wynikowe drzewo, zobaczysz jaką sumę SHA-1 plik repo.rb otrzymał:

Następnie możesz sprawdzić przy pomocy git cat-file ile miejsca zajmuje on na dysku:

Teraz, zmodyfikujmy nieco ten plik i sprawdźmy co się stanie:

Sprawdź ponownie wynikowe drzewo projektu, a zobaczysz coś interesującego:

Obiekt blog jest teraz zypełnie inny, co oznacza, że pomimo tego że dodałeś tylko jedną linię na końcu pliku który miał 400 linii, Git zapisał całą nową zawartość jako nowy obiekt:

Masz teraz dwa prawie takie same obiekty zajmujące 22KB na dysku. Czy nie byłoby fajnie, gdyby Git mógł przechowywać tylko jeden z nich, a drugi tylko jako różnicę między nim a pierwszym?

Okazuje się że może. Początkowym formatem w jakim Git przechowuje obiekty na dysku jest tak zwany "luźny" format. Jednak, czasami Git pakuje kilka obiektów w pojedynczy plik binarny określany jako "packfile", aby zmniejszyć użycie przestrzeni dyskowej i przez to być bardziej wydajnym. Git wykona to, jeżeli masz dużą ilość luźnych obiektów, jeżeli uruchomisz komendę git gc, lub jeżeli wypchniesz dane na zdalny serwer. Aby zobaczyć jak to wygląda, możesz ręcznie zmusić Gita aby spakował te obiekty, za pomocą wywołania komendy git gc:

Jak spojrzysz na katalog "objects", zauważysz że większość Twoich obiektów zniknęła i pojawiła się para nowych plików:

Obiekty blob które pozostały, to obiekty które nie wskazywały na żaden obiekt commit – w tym przypadku, przykładowe obiekty blob "what is up, doc?" oraz "test content", które zostały stworzone wcześniej. Ponieważ nie zostały one nigdy powiązane z żadnym commitem, Git uznał że nie są z niczym powiązane i nie włączył ich do żadnego pliku packfile.

Kolejne nowe pliki to plik packfile oraz indeks. Plik packfile to pojedynczy plik, zawierający zawartość wszystkich obiektów które zostały usunięte. Plik indeks zawiera informacje o tym, w którym miejscu w pliku packfile znajduje się konkretny obiekt. Co jest ciekawe, to to, że przed uruchomieniem gc obiekty na dysku zajmowały łącznie około 22KB, a nowy plik packfile tylko 7KB. Przez spakowanie obiektów, zmniejszyłeś o ⅔ ilość zajmowanego miejsca.

W jaki sposób Git to robi? Gdy Git pakuje obiekty, szuka plików które pod względem nazwy pliku i rozmiaru są podobne, i zachowuje tylko różnicę między wersjami. Możesz obejrzeć zawartość pliku packfile i zobaczyć co Git zrobił aby ograniczyć zużycie przestrzeni dyskowej. Komenda git verify-pack pozwala na podgląd tego, co zostało spakowane:

Tutaj, blob 033b4, który, jeśli pamiętasz, był pierwszą wersją twojego pliku repo.rb, odwołuje się do bloba b042a, który był drugą wersją tego pliku. Trzecia kolumna na wyjściu to rozmiar obiektu w paczce, więc możesz zobaczyć, że b042a zajmuje 22KB pliku, ale 033b4 zajmuje tylko 9 bajtów. Co jest również interesujące, druga wersja pliku jest tą, która jest przechowywana nienaruszona, podczas gdy oryginalna wersja jest przechowywana jako delta – jest to spowodowane tym, że najprawdopodobniej będziesz potrzebował szybszego dostępu do najnowszej wersji pliku.

Naprawdę miłą rzeczą w tym jest to, że może być przepakowany w dowolnym momencie. Git będzie od czasu do czasu automatycznie przepakowywał Twoją bazę danych, zawsze starając się zaoszczędzić więcej miejsca, ale możesz również ręcznie przepakować ją w dowolnym momencie uruchamiając git gc ręcznie.