10.2 Mechanizmy wewnętrzne w Git - Obiekty Gita

Następnym typem obiektów ,który poznasz, są obiekty drzew (ang. tree), które rozwiązują problem przechowywania nazw plików oraz pozwalają na przechowywanie grupy plików razem. Git przechowuje treść w sposób podobny do systemu plików UNIX, lecz z pewnymi uproszczeniami. Wszystkie dane przechowywane są jako obiekty "tree" i "blob", z obiektami "tree" odpowiadającymi strukturze katalogów w systemie UNIX, oraz obiektami "blob", które w mniejszym lub większym stopniu odpowiadają i-węzłom lub treści plików. Pojedynczy obiekt "tree" zawiera jeden lub więcej wpisów dotyczących ścieżki, z których każdy zawiera skrót SHA-1 wskazujący na obiekt "blob" lub poddrzewem (ang. subtree) z przypisanym trybem, typem i nazwą pliku. Na przykład, najnowsze drzewo w projekcie może wygląda tak:

Składnia master^{tree} wskazuje na obiekt tree na który wskazuje ostatni commit w Twojej gałęzi master. Zauważ, że podkatalog lib nie jest blobem, ale wskaźnikiem na inny obiekt tree.

W ogólnym zarysie, dane, które przechowuje Git , wyglądają podobnie do tych pokazanych poniżej:

Możesz stworzyć swój własny obiekt tree. Git zazwyczaj tworzy taki obiekt poprzez pobranie stanu przechowalni lub indeksu i zapisanie obiektu tree z tych danych. A więc, aby stworzyć obiekt tree, na początek musisz ustawić indeks poprzez dodanie do przechowalni plików. Indeks z jednym elementem – z pierwszą wersją Twojego pliku test.txt – możesz stworzyć używając komendy update-index. Możesz jej również do sztucznego dodania poprzedniej wersji pliku test.txt do przechowalni. Musisz podać jej opcje --add ponieważ plik nie istnieje jeszcze w przechowalni (nie masz jeszcze nawet ustawionej przechowalni) oraz --cacheinfo ponieważ plik który dodajesz nie istnieje w katalogu, a tylko w bazie danych. Następnie wskazujesz tryb, sumę SHA-1 oraz nazwę pliku:

W tym przykładzie, podałeś tryb 100644, który wskazuje na normalny plik. Inne dostępne tryby to 100755, który wskazuje na plik wykonywalny; oraz 120000, który wskazuje na dowiązanie symboliczne. Tryby bazują na normalnych uprawnieniach w systemie UNIX, ale mają znacznie mniej opcji – te trzy tryby są jedynymi, które mogą być stosowane do plików (blob-ów) w Gitcie (chociaż inne tryby mogą być użyte dla katalogów i podmodułów).

Teraz, możesz użyć komendy write-tree, w celu zapisania zawartości przechowani do obiektu tree. Opcja -w nie jest potrzebna – wywołanie write-tree automatycznie tworzy obiekt tree ze stanu indeksu, jeżeli ten obiekt jeszcze nie istnieje.

Możesz również zweryfikować, że to jest obiekt tree:

Stworzysz teraz nowy obiekt tree, zawierający drugą wersję pliku test.txt oraz nowy plik:

W Twojej przechowalni znajduje się teraz nowa wersja pliku test.txt oraz nowy plik new.txt. Zapisz ten stan (pobierając stan z przechowalni lub indeksu do obiektu tree) i sprawdź jak on teraz wygląda:

Zauważ, że to drzewo posiada oba wpisy dotyczące plików, oraz że suma SHA w pliku test.txt jest sumą przypisaną do "wersji 2" (1f7a7a). Dla zabawy, dodasz pierwszy obiekt tree jako podkatalog w obecnym. Możesz wczytać obiekt tree do swojej przechowalni poprzez wywołanie read-tree. W takim wypadku, możesz wczytać obecne drzewo do swojej przechowalni i umieścić je w podkatalogu za pomocą opcji --prefix dodanej do read-tree:

Jeżeli odtworzyłeś katalog roboczy z drzewa które właśnie zapisałeś, otrzymałeś dwa pliki na najwyższym poziomie w tym katalogu, oraz podkatalog bak, który zawiera pierwszą wersję pliku test.txt. Możesz myśleć o danych przechowywanych w Gitcie z tymi strukturami, tak jak przedstawiono to poniżej:

Masz teraz trzy obiekty tree, które wskazują na różne migawki śledzonego projektu, ale poprzedni problem pozostał: musisz pamiętasz wszystkie trzy wartości SHA-1 aby przywrócić migawkę. Nie masz również żadnych informacji o tym kto zapisał migawkę, kiedy była zapisana, ani dlaczego. To są podstawowe informacje, które przechowywane są w obiektach typu commit.

Aby stworzyć obiekt commit, wywołaj commit-tree i podaj jedną sumę SHA-1 wskazującą na obiekt tree oraz obiekty commit, o ile były jakieś, które bezpośrednio go poprzedziły. Zacznij od pierwszego obiektu tree, który napisałeś:

Możesz teraz zobaczyć jak wygląda nowy obiekt commit za pomocą cat-file:

Format obiektu commit jest prosty: wskazuje on najnowszy obiekt tree dla migawki projektu w momencie tworzenia; informacje o autorze/integratorze zmiany pobrane z są ustawień konfiguracyjnych user.name i user.email wraz z obecnym znacznikiem czasu; pustą linię i potem treść komentarza do zmiany.

Następnie, zapiszesz dwa inne obiekty commit, z których każdy odwołuje się do commit-a który był bezpośrednio przed nim:

Każdy z trzech obiektów commit wskazuje na jedną z trzech migawek które stworzyłeś. Co ciekawe, masz teraz prawdziwą historię w Git, którą możesz obejrzeć za pomocą komendy git log, jeżeli uruchomisz ją na ostatniej sumą SHA-1 obiektu commit:

Niesamowite. Wykonałeś właśnie niskopoziomowe operacje i stworzyłeś historię w Git bez używania żadnej z komend użytkownika. Jest to w zasadzie to, co Git robi kiedy uruchomisz komendy git add oraz git commit – zapisuje obiekty blob dla plików które zmieniłeś, aktualizuje indeks, zapisuje obiekt tree, oraz tworzy obiekt commit odnoszący się do obiektu tree oraz obiektów commit które wystąpiły bezpośrednio przed nim. Te trzy główne obiekty Gita – blob, tree oraz commit – są na początku zapisywane jako pojedyncze pliki w katalogu .git/objects. Poniżej widać wszystkie obiekty z naszego przykładu, z komentarzami wskazującymi na to co było w nich zapisane:

Jeżeli prześledzisz wszystkie wskaźniki, dostaniesz widok obiektów podobny do poniższego:

Wspomnieliśmy wcześniej, że nagłówek jest zapisywany wraz z treścią. Spójrzmy przez chwilę w jaki sposób Git zapisuje swoje obiekty. Zobaczysz jak zapisać obiekt blob – na przykładzie treści "what is up, doc?" – interaktywnie w języku skryptowym Ruby.

Możesz uruchomić tryb interaktywny w Rubym, za pomocą komendy irb:

Git tworząc nagłówek na początku wskazuje jakiego typu jest obiekt, w tym wypadku blob. Następnie, dodaje spację i wielkość treści, oraz na końcu pusty znak (null):

Git łączy nagłówek z treścią, a potem oblicza sumę SHA-1 całości. Możesz obliczyć sumę SHA-1 dla treści w Ruby, po włączeniu biblioteki "SHA1 digest" za pomocą komendy require, oraz po wywołaniu Digest::SHA1.hexdigest() na nim:

Git kompresuje nową treść za pomocą zlib, co możesz wykonać w Ruby przy użyciu biblioteki zlib. Najpierw, musisz dodać wpis require, a potem uruchomić na treści Zlib::Deflate.deflate():

Na koniec, zapiszesz spakowaną treść jako obiektu na dysku. Ustalisz ścieżkę dla obiektu który zapisujesz (pierwsze dwa znaki z sumy SHA-1 są nazwą podkatalogu, a pozostałe 38 znaków są nazwą pliku w tym katalogu). W Ruby możesz użyć funkcji FileUtils.mkdir_p(), aby stworzyć podkatalog w przypadku gdy on nie istnieje. Następnie otwórz plik za pomocą File.open() i zapisz otrzymaną skompresowaną zawartość do pliku za pomocą funkcji write() wywołanej na otrzymanym uchwycie pliku:

To tyle – stworzyłeś poprawny obiekt blog w Gitcie. Wszystkie obiekty w Git przechowywane są w taki sam sposób, tylko z innymi typami – zamiast ciągu znaków blob, nagłówek będzie rozpoczynał się od commit lub tree. Choć obiekt blob może zawierać praktycznie dowolne dane, to jednak obiekty commit i tree są bardzo specyficznie sformatowane.