Praktyczny kurs GIT dla zielonych cz. 4 – Stash i Tagi

Dziś zajmiemy się nieco rzadziej wykorzystywanymi funkcjami gita, jak stash i tagi. Bliżej przyjrzymy się temu, jak przeskakiwać między branchami mimo wcześniej zrobionych zmian, oraz jak oznaczać kolejne wersje naszego projektu w sensowny sposób. Zapraszam!

Spis treści

  1. Stash
    • Czym jest stash?
    • Przykład użycia
  2. Tagi
    • Czym są tagi?
    • Jak poprawnie tagować?
    • Przykład użycia
  3. Podsumowanie

Stash

Czasem może przydarzyć się sytuacja, w której zachodzi potrzeba przełączenia się na inny branch bez wcześniejszego robienia commita. Dlaczego ktoś by miał to robić? A no dlatego, że zgodnie z filozofią git, nie powinno się wrzucać niedziałającego/niedokończonego kodu. Kolejne commity powinny stanowić swoiste checkpointy w działającym projekcie, tak jak w grach komputerowych (więcej o dobrych praktykach będzie w kolejnej części poradnika).

Z pomocą przychodzi git stash, czyli schowek. Zmiany zostają zapisane w pamięci lokalnego repozytorium, podobnie jak w przypadku commita. Nie są jednak pushowane do zdalnego repozytorium. Oznacza to, że zmiany w stashu pozostają tylko w lokalnym repozytorium w którym zostały wykonane.

Komendą git stash możemy zapisać nasze zmiany do schowka. Każde kolejne zmiany są zapisywane oddzielnie. Za pmocą git stash list możemy mieć wgląd do ich listy. Komenda ta jest ważna, ponieważ na liście ponazywane są kolejne nazwy (indeksy) zestashowanych zmian, które potem będziemy chcieli wprowadzić np. za pomocą git stash apply nazwa. Zapisane zmiany w schowku można usuwać, tworzyć z nich branche i robić z nimi wiele innych ciekawych rzeczy, które są bardzo dobrze opisane na git-scm w języku polskim, dlatego nie będę bez potrzeby powielał tych samych treści. Zainteresowanych zapraszam do lektury.

Tagi

Używając różnych programów często można zauważyć informację o wersji aplikacji np. 3.14.42.1337. Jedni oznaczają ją za pomocą v1, v2, v3… Inni używają dwóch liczb oddzielonych kropką, jeszcze inni wersje oznaczają np. jako skróty identyfikatora commita. W praktyce, najlepszą (moim zdaniem) konwencją jest oznaczanie wersji sekwencją trzech lub czterech liczb (więcej o różnych konwencjach). W tym przypadku kolejne liczby oznaczają:

  • Major (numer główny),
  • Minor (numer dodatkowy),
  • Release (numer wydania),
  • Build (opcjonalny, stosowane głównie w przypadku często zmieniających się wersji developerskich)

W podanym wyżej przykładzie program ma wersję major: 3, minor: 14, release:42 i build:1337. Jeśli w ogóle używa się buildu, to jest inkrementowany zazwyczaj przy każdej kolejnej kompilacji projektu, po wprowadzeniu nawet najmniejszych zmian. Zmiany członu release występują głównie w przypadku wprowadzania drobnych poprawek. Wersja minor powinna być zwiększana kiedy wprowadzamy nowe funkcjonalności do projektu, jednak wszystkie stare feature’y i ustawienia są w pełni kompatybilne z nową wersją. Zmiana major’a oznacza zazwyczaj całkowitą lub częściową przebudowę aplikacji, z którą może wiązać się utrata wstecznej kompatybilności.

Tyle z teorii, pewnie i tak każdy zrobi po swojemu. Przynajmniej próbowałem 😛 Teraz czas wrócić do git’a.

Tagi to nic innego jak wskaźniki (lub jak kto woli etykiety) konkretnych commitów. Zamiast szukać w historii 50 commitów wsteccz, gdzie była ta wersja co w niej akurat działało a potem już przestało, można od razu skoczyć do konkretnego commita za pomocą wersji. Załóżmy że nasza aplikacja jest już gotowa. Nadajmy jej zatem wersję 1.0.0. Zapewne pojawi się kilka drobnych błędów, które poprawimy w wersji 1.0.1 (i być może kolejnych). Realizacja naszego planu wygląda następująco:

 

Po wpisaniu ostatniej komendy powinna wyświetlić się w rezultacie lista aktualnie istniejących tagów:

Gdy zrobimy git push origin nazwa_brancha zauważymy jednak, że tagi nie zostały spushowane. Do repo zdalnego zostały wysłane wyłącznie commity. Aby spushować commity razem z poczynionymi przez nas tagami należy użyć parametru –tags w następujący sposób:

Oczywiście za master można podstawić dowolną nazwę brancha, na którym pracujemy. Dzięki takiemu zabiegowi powinniśmy uzyskać efekt podobny do tego:

Jeśli będziemy chcieli teraz przeskoczyć na starszą wersję projektu, wystarczy zrobić git checkout 1.0.0 i automatycznie aktualny commit na którym będziemy pracować przejdzie do stanu otagowanego 1.0.0. W przypadku chęci powrotu do przyszłości ( 😀 ) wystarczy git checkout master.

Podsumowanie

Tak oto powoli zbliżamy się do końca kursu. Te kilka stron maszynopisu to tylko namiastka tego, co potrafi git. Nie widzę jednak sensu opisać wszystkich jego możliwości, gdyż od tego jest dokumentacja techniczna. W końcu jest to kurs kierowany do początkujących 🙂 W ostatniej części kursu poruszę sprawę dobrych praktyk. Doradzę co wrzucać na .git’a, a czego nie? Podpowiem też, jak uniknąć uciążliwego wpisywania hasła przy każdym pullu/pushu do repozytorium zdalnego. Do zobaczenia!