Oczyszczanie środowiska Git

Wynik uzyskany po wykonaniu polecenia git log będzie wskazywał 2 commity oraz odpowiednie komunikaty commitów dotyczące zmian wprowadzonych w pliku hello.txt. Kolejnym krokiem w naszym przypadku jest ustawienie jednego z commitów jako nieosiągalnego. Wykorzystamy w tym celu polecenie git reset. Przywrócimy repozytorium do stanu pierwszego commita, czyli „added hello.txt”.

Jeśli teraz użyjemy pliku git log do zbadania stanu repozytorium, zobaczymy, że mamy tylko jeden commit.

Repozytorium demonstracyjne zawiera teraz odłączony commit. Drugi wykonany commit opatrzony komunikatem „added another line to hello.txt” nie jest już wyświetlany w wynikach polecenia git log i jest teraz odłączony. Może się wydawać, że commit został utracony lub usunięty, ale Git bardzo rygorystycznie traktuje nieusuwanie historii. Możemy potwierdzić, że jest on dostępny, ale odłączony, przechodząc do niego bezpośrednio za pomocą polecenia git checkout:

Jeśli wyewidencjonujemy odłączony commit, Git jest na tyle przemyślany, że zwróci nam szczegółowy komunikat z wyjaśnieniem, że pracujemy w stanie odłączonym. Jeśli przeanalizujemy przedstawiony tutaj dziennik, zauważymy, że commit „added another line to hello.txt” znajduje się z powrotem w wygenerowanym dzienniku. Teraz, gdy wiemy, że repozytorium znajduje się w odpowiednim stanie symulacji z odłączonym commitem, możemy przećwiczyć polecenie git prune. Jednak najpierw wróćmy do gałęzi main za pomocą polecenia git checkout.

Gdy wrócimy do gałęzi main za pomocą polecenia git checkout, Git po raz kolejny przemyślnie powiadomi nas, że opuszczamy odłączony commit. Przyszedł czas na oczyszczenie odłączonego commita. Teraz wykonamy polecenie git prune, jednak najpierw musimy przekazać do niego pewne opcje. Opcje --dry-run i --verbose spowodują wyświetlenie wyniku ze wskazaniem, co zostanie oczyszczone, bez wykonywania faktycznej operacji oczyszczania.

Polecenie to najprawdopodobniej zwróci pusty wynik. Pusty wynik oznacza, że operacja oczyszczenia nie spowoduje usunięcia niczego. Dlaczego tak się dzieje? Cóż, najprawdopodobniej commit nie został w pełni odłączony. Gdzieś w Git wciąż znajduje się do niego referencja. To doskonały przykład ilustrujący, dlaczego polecenia git prune nie należy używać niezależnie od polecenia git gc. Jest to również dobry przykład tego, jak trudno jest całkowicie utracić dane w Git.

Najprawdopodobniej Git przechowuje referencję do naszego odłączonego commita w dzienniku reflog. Możemy to przeanalizować, wykonując polecenie git reflog. Powinien wyświetlić się wynik z opisem sekwencji czynności wykonanych, zanim doszliśmy do tego momentu. Więcej informacji na temat polecenia git reflog można znaleźć na stronie git reflog. Oprócz zachowania historii w dzienniku reflog, Git ma wewnętrzne daty ważności, zgodnie z którymi odłączone commity są oczyszczane. To wszystko również są szczegóły wdrożeniowe, z którymi radzi sobie git gc, co potwierdza, że polecenia git prune nie należy używać niezależnie.

Aby zakończyć naszą demonstrację symulującą działanie polecenia git prune, musimy wyczyścić dziennik reflog.

Powyższe polecenie wymusi wygaśnięcie wszystkich wpisów w dzienniku reflog, które zostały dodane wcześniej niż teraz. Jest to brutalne i niebezpieczne polecenie i na co dzień użytkownik Git nie powinien się znaleźć w sytuacji wymagającej jego użycia. My wykonujemy to polecenie, aby zademonstrować udane wykonanie operacji git prune. Po całkowitym wyczyszczeniu dziennika reflog możemy wykonać polecenie git prune.

To polecenie powinno zwrócić listę referencji do obiektów w formie hashy Git podobną do powyższej.

Poleceniu git prune towarzyszy krótka lista opcji omówionych w sekcji przeglądu.

Nie wykonuj operacji oczyszczania. Po prostu wyświetl wynik, który uzyskamy w przypadku jej wykonania.

Wyświetl dane wyjściowe wszystkich obiektów i działań uwzględnionych w operacji oczyszczania.

Wyświetla wynik wskazujący postęp operacji oczyszczania.

Wymuś wygaśnięcie obiektów, które są wcześniejsze niż

Zdefiniowanie parametru spowoduje zachowanie wszelkich opcji z tej referencji head.

Polecenia git remote prune i git fetch --prune pełnią taką samą funkcję: usuwają referencje do gałęzi nieistniejących w repozytorium zdalnym. Jest to wysoce pożądane podczas pracy w ramach zespołowego przepływu pracy, w którym gałęzie zdalne są usuwane po scaleniu z gałęzią main. Drugie polecenie — git fetch --prune — spowoduje połączenie z repozytorium zdalnym i pobranie najnowszego stanu gałęzi zdalnej przed wykonaniem oczyszczania. Jest to zasadniczo kombinacja następujących poleceń:

Ogólne polecenie git prune jest całkowicie inne. Jak omówiono w sekcji przeglądu, polecenie git prune powoduje usunięcie lokalnie odłączonych commitów.

Polecenie git fetch --prune jest najlepszym narzędziem do oczyszczania nieaktualnych gałęzi. Nawiązuje ono połączenie ze współdzielonym zdalnym repozytorium i pobiera wszystkie referencje gałęzi zdalnych. Następnie usuwa referencje gałęzi zdalnych, które już nie są używane w repozytorium zdalnym.

Nie, polecenie git remote prune origin spowoduje jedynie usunięcie referencji do gałęzi zdalnych, które już nie istnieją. W Git przechowywane są zarówno referencje lokalne, jak i zdalne. Repozytorium będzie zawierało zbiór referencji local/origin i remote/origin. Polecenie git remote prune origin spowoduje oczyszczenie referencji jedynie w zbiorze remote/origin. Praca lokalna pozostanie bezpieczna w zbiorze local/origin.

Polecenie git prune wywoływane jest jako polecenie podrzędne względem polecenia git gc. W trakcie codziennych prac programistycznych konieczność wywołania polecenia git prune jest mało prawdopodobna. Do zrozumienia skutków działania polecenia git prune konieczne jest odwołanie się do innych poleceń. W tym artykule użyliśmy między innymi takich poleceń, jak git log, git reflog i git checkout.