10.7 Mechanizmy wewnętrzne w Git - Konserwacja i odzyskiwanie danych

Sporadycznie Git uruchamia automatycznie komendę auto gc`. Najczęściej ta komenda nic nie robi. Jednak, jeżeli istnieje za dużo luźnych obiektów (obiektów które nie są w plikach packfile), lub za dużo plików packfile, Git uruchamia pełną komendę git gc. Komenda gc (od ang. garbage collect) wykonuje różne operacje: gromadzi ona wszystkie luźne obiekty i umieszcza je w plikach packfile, łączy pliki packfile w jeden duży, oraz usuwa obiekty które nie są osiągalne przez żaden z commitów i są starsze niż kilka miesięcy.

Możesz uruchomić auto gc` ręcznie w ten sposób:

I znowu, ona generalnie nic nie robi. Musisz mieć około 7000 luźnych obiektów, lub więcej niż 50 plików packfile, aby Git odpalił pełną komendę gc. Możesz zmienić te limity za pomocą ustawień konfiguracyjnych gc.auto oraz gc.autopacklimit.

Inną rzeczą którą komenda gc zrobi, jest spakowanie referencji do pojedynczego pliku. Załóżmy, że Twoje repozytorium zawiera następujące gałęzie i etykiety:

Jeżeli uruchomisz git gc, nie będziesz miał już tych plików w katalogu refs. Git przeniesie je, w celu poprawienia wydajności do pliku .git/packed-refs, który wygląda tak:

Jeżeli zaktualizujesz referencje, Git nie będzie zmieniał tego pliku, ale zamiast tego stworzy nowy plik w refs/heads. Aby pobrać właściwą sumę SHA-1 dla danej referencji, Git sprawdzi czy istnieje ona w katalogu refs, a następnie sprawdzi plik packed-refs. Jeżeli nie możesz znaleźć referencji w katalogu refs, jest ona prawdopodobnie w pliku packed-refs.

Zauważ, że ostatnia linia w tym pliku zaczyna się od ^. Oznacza to, że dana etykieta jest etykietą opisaną, a ta linia jest commitem na który on wskazuje.

W pewnym momencie swojej pracy z Git, możesz czasami przez przypadek stracić commit. Zazwyczaj dzieje się tak dlatego, ponieważ wymusisz usunięcie gałęzi która miała w sobie zmiany, a okazuje się że jednak ją potrzebowałeś; lub wykonujesz na gałęzi hard-reset, porzucając zmiany które teraz potrzebujesz. Zakładając że tak się stało, w jaki sposób możesz odzyskać swoje zmiany?

Mamy tutaj przykład, na którym zobaczymy odzyskiwanie danych z testowego repozytorium na którym wykonano hard-reset na gałęzi master. Na początek, zobaczmy jak wygląda repozytorium w takiej sytuacji:

Teraz cofnij gałąź master do środkowej zmiany:

W ten sposób, skutecznie utraciłeś dwa najnowsze commity – nie masz gałęzi z której można by się dostać do nich. Musisz znaleźć najnowszą sumę SHA, a potem dodać gałąź wskazującą na nią. Najtrudniejsze jest znalezienie ostatniej sumy SHA-1 – przecież nie zapamiętałeś jej, prawda?

Często, najszybszym sposobem jest użycie narzędzia git reflog. W czasie pracy, Git w tle zapisuje na co wskazuje HEAD po każdej zmianie. Za każdym razem gdy wykonujesz commit lub zmieniasz gałęzie, reflog jest aktualizowany. Reflog jest również aktualizowany przez komendę git update-ref, co jest kolejnym argumentem za tym, aby jej używać zamiast zapisywać bezpośrednio wartości SHA-1 do plików ref, tak jak zostało to opisane wcześniej w sekcji Referencje w Git. Możesz zobaczyć na jakim etapie był projekt w każdym momencie za pomocą komendy git reflog:

Widzimy tutaj dwa commity które pobraliśmy, jednak nie mamy za dużo informacji. Aby zobaczyć te same informacje w bardziej użytecznej formie, możemy uruchomić git log -g, która pokaże normalny wynik działania komendy log dla refloga:

Wygląda na to, że dolny commit to jeden z tych które utraciłeś, możesz go odzyskać przez stworzenie nowej gałęzi wskazującej na niego. Na przykład, możesz dodać gałąź recover-branch wskazującą na ten commit (ab1afef):

Świetnie – masz teraz gałąź recover-branch, która wskazuje na miejsce w którym był master, pozwalając tym samym na dostęp do pierwszych dwóch commitów. Następnie, załóżmy że utracone zmiany z jakiegoś powodu nie były w reflogu – możesz to zasymulować poprzez usunięcie recover-branch i usunięcie refloga. Teraz pierwsze dwa commity nie są dostępne w żaden sposób:

Ponieważ dane reflog są przechowywane w katalogu .git/logs/, w rzeczywistości nie masz refloga. W jaki sposób odtworzyć ten commit w tym momencie? Jednym ze sposobów jest użycie narzędzia git fsck, które sprawdza zawartość bazy pod względem integralności danych. Jeżeli uruchomisz go z opcją --full, pokaże on wszystkie obiekty do których nie da się dotrzeć przez inne:

W tym przypadku, możesz zobaczyć brakujący commit oznaczony jako "opuszczony" (ang. dangling). Możesz odtworzyć go w ten sam sposób, poprzez dodanie gałęzi wskazującej na jego SHA-1.

Można powiedzieć dużo dobrego o Gitcie, ale jedną z funkcjonalności która może powodować problemy jest fakt, że git clone pobiera całą historię projektu, włącznie z każdą wersją wszystkich plików. Jest to dobre rozwiązanie, jeżeli całość to kod źródłowy, ponieważ Git został przygotowany do tego aby efektywnie kompresować takie dane. Jednak, jeżeli w jakimś momencie trwania projektu, ktoś dodał pojedynczy duży plik, podczas klonowania repozytorium zawsze będzie on pobierany, nawet jeżeli został usunięty z projektu w następnym commicie. Ze względu na to, że można do niego dostać się przez historię projektu, zawsze tam będzie.

Może to być dużym problemem podczas konwersji repozytoriów Subversion lub Perforce do Gita. Ponieważ nie pobierasz w nich całej historii projektu, dodanie tak dużego pliku będzie powodowało pewne konsekwencje. Jeżeli wykonałeś import z innego systemu lub zobaczyłeś, że Twoje repozytorium jest dużo większej niż być powinno, poniżej prezentuję sposób na usunięcie dużych obiektów.

Ostrzegamy: ta technika działa destrukcyjnie na Twoją historię zmian. Nadpisuje ona każdy obiekt, począwszy od najwcześniejszego który trzeba zmodyfikować aby usunąć odwołanie do pliku. Jeżeli wykonasz to od razu po zaimportowaniu, zanim ktokolwiek rozpoczął pracę bazującą na nich, wszystko będzie w porządku – w przeciwnym wypadku, będziesz musiał poinformować wszystkich współpracowników o tym, że muszą wykonać rebase na nowe commity.

W celach demonstracyjnych, dodasz duży plik do swojego testowego repozytorium, usuniesz go w kolejnym commicie, odszukasz go i następnie usuniesz na stałe z repozytorium. Najpierw dodaj duży plik do repozytorium:

Ojej – nie chciałeś dodać tego dużego pliku do projekt. Najlepiej go usuń:

Teraz, uruchom gc na bazie danych i zobacz jak dużo miejsca jest zajmowane:

Możesz uruchomić komendę count-objects, aby szybko zobaczyć jak dużo miejsca jest zajmowane:

Wpis size-pack pokazuje wielkość plików packfile wyrażonych w kilobajtach, więc używasz 5MB. Przed ostatnim commitem, używałeś blisko 2KB – a więc jasno widać, że usunięcie pliku w poprzednim commitcie nie usunęło go z historii. Za każdym razem, gdy ktoś sklonuje to repozytorium, będzie musiał pobrać całe 5MB aby pobrać ten malutki projekt, tylko dlatego że pochopnie dodałeś duży plik. Naprawmy to.

Najpierw będzie musiał go znaleźć. W naszym wypadku, wiesz jaki plik to był. Ale załóżmy że nie wiesz; w jaki sposób dowiesz się jaki plik lub pliki zajmują tyle miejsca? Po uruchomieniu git gc, wszystkie obiekty są w plikach packfile; ale możesz zidentyfikować duże obiekty przez uruchomienie komendy git verify-pack i posortowanie wyniku po trzeciej kolumnie, oznaczającej rozmiar pliku. Możesz również przekazać wynik do komendy tail ponieważ jesteś zainteresowany tylko kilkoma największymi plikami:

Duży obiekt jest na samym dole: 5MB. Aby dowiedzieć się jaki to jest plik, użyjesz komendy rev-list, której miałeś okazję już poznać w sekcji Enforcing a Specific Commit-Message Format. Jeżeli przekażesz opcję --objects do rev-list, w wyniku pokazane zostaną sumy SHA-1 commitów oraz obiektów blob z przyporządkowanymi do nich nazwami plików. Możesz użyć tej komendy, aby odnaleźć nazwę obiektu blob:

Musisz teraz usunąć ten plik ze wszystkich starszych rewizji. Możesz łatwo zobaczyć, które commity zmodyfikowały ten plik:

Musisz nadpisać wszystkie commity starsze niż 7b30847, aby w pełni usunąć ten plik z historii projektu w Git. Aby to zrobić, użyjesz komendy filter-branch, poznanej w sekcji Przepisywanie historii:

Opcja --index-filter jest podobna do opcji --tree-filter opisanej w sekcji Przepisywanie historii, z tą różnicą, że zamiast przekazywać komendę, która modyfikuje pobrane pliki na dysku, modyfikuje przechowalnię lub indeks za każdym razem.

Zamiast usuwać konkretny plik za pomocą rm file, musisz usunąć go za pomocą git rm --cached – musisz usunąć go z indeksu, nie z dysku. Powodem do takiego zachowania jest szybkość – ponieważ Git nie musi pobrać każdej rewizji na dysk przed uruchomieniem filtra, cały proces może być dużo szybszy. Możesz osiągnąć taki sam efekt za pomocą --tree-filter, jeżeli chcesz. Opcja --ignore-unmatch do git rm wskazuje, aby nie pokazywać błędu w przypadku, gdy szukana ścieżka nie istnieje. Na koniec, wskazujesz filter-branch, aby przepisana została historia począwszy od 7b30847, ponieważ wiesz że właśnie tam problem powstał. W przeciwnym razie, rozpocznie ona działanie od początku i przez to będzie trwała niepotrzebnie dłużej.

Twoja historia nie zawiera już odwołań do tego pliku. Ale reflog i nowe referencje które zostały dodane, wtedy gdy uruchomiłeś filter-branch w .git/refs/original nadal tak, musisz więc je usunąć i przepakować bazę danych. Musisz pozbyć się wszystkiego co wskazuje na te stare commity przed przepakowaniem:

Zobaczmy ile miejsca udało się zaoszczędzić.

Wielkość spakowanego repozytorium to teraz 8K, co jest dużo lepszym wynikiem niż 5MB. Możesz odczytać z wartości "size", że ten duży obiekt nadal znajduje się w repozytorium, nie został więc całkowicie usunięty; jednak co najważniejsze, nie będzie już przesyłany podczas wykonywania push lub klonowania. Jeżeli mocno chcesz, możesz usunąć ten obiekt całkowicie przez uruchomienie komendy git prune --expire: