Dzięki mechanizmowi tagowania i operacji git tag – możemy w wydajny sposób oznaczyć i później pobrać praktycznie dowolny punkt w historii naszych zmian.
W ramach tego materiału dowiesz się jak pracować z Gitem i praktycznie wykorzystać tagowanie w codziennej pracy.
Spis treści
Git tag – tagowanie w git, add, push, checkout – wprowadzenie
Z tego materiału dowiesz się:
- Na czym polega mechanizm tagowania w git
- Jak działa metoda git tag
- Jak dodawać, usuwać, modyfikować oraz współdzielić tagi w git
Systemy kontroli wersji odpowiedzialne są za śledzenie wszystkich zmian dokonywanych w plikach. Za ich pomocą można podejrzeć wcześniej dokonane zmiany oraz, w razie potrzeby, powrócić do starszej wersji pliku. Dzięki nim można również sprawdzić kto i kiedy dokonał tych zmian.
Obecnie Git jest najpopularniejszym rozproszonym systemem kontroli wersji. System pierwotnie został stworzony przez Linusa Torvalds jako narzędzie wspomagające rozwój jądra Linux i od tego czasu sukcesywnie zyskuje na popularności.
Git oficjalnie został wydany w 2005 roku i obecnie jest rozwijany na zasadach wolnej licencji – a co za tym idzie, swobodnie możemy go wykorzystywać w naszych projektach.
W ramach tego materiału zajmiemy się przede wszystkim pracą z tagami – natomiast kompletny tutorial Git znajdziesz poniżej.
➡ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone
Git install – Instalacja GitJeżeli nie masz jeszcze gita zainstalowanego lokalnie – szybko możesz to nadrobić.
W poniższym materiale znajdziesz instrukcję, jak można to zrobić.
➡ ZOBACZ 👉: Install Git – Instalacja Git, Windows, Ubuntu – Bash, GUI
Git tagTym razem porozmawiamy o koncepcji tagowania w git oraz komendzie git tag.
Zacznijmy od wyjaśnienia, po co właściwie potrzebne są nam tagi.
Tagi pozwalają nam na wskazanie pewnego konkretnego punktu w historii gita.
Korzystając z komendy git log – lub bardziej skompresowanej wersji git log –pretty=oneline możemy wyświetlić historię naszych commitów.
Jeden wpis w historii odpowiada jednemu commitowi – czyli jednej utrwalonej przez nas zmianie.
Przy pomocy tagu możemy wskazać jeden z takich punktów w historii.
Możemy np. oznaczyć pewien stan aplikacji jako na tyle stabilny, że chcemy, żeby został wydany jako nowa wersja.
Takie podejście do tagowania (git tag) jest trochę podobne do brancha, który już się nie zmienia.
Analogicznie jak w przypadku gałęzi możemy zrobić git checkout tag – czyli pobrać zmiany wskazywane przez ten tag – co swoją drogą za chwilę zrobimy.
Zobaczmy ,co znajdziemy w pomocy o naszych tagach: git tag –help.
Wyświetlmy list tagów z aktualnego repozytorium przy pomocy komendy: git tag.
Mamy ich tutaj całkiem sporo (dla przypomnienia korzystamy z repozytorium przechowującego kod źródłowy samego gita – https://github.com/git/git)
Podobne informacje – w razie potrzeby moglibyśmy znaleźć na GUI po stronie GitHub.
Ponieważ w naszym repozytorium mamy prawie 1000 tagów – dość ciężko się w tym połapać.
Spróbujmy w takim razie przefiltrować je według zadanych kryteriów – możemy to zrobić, np. korzystając z takiej komendy: git tag -l *-rc*.
W ten sposób odfiltrowaliśmy tagi, które zostały oznaczone jako kandydaci do wydania (ang. rc – release candidate).
Git add tag
Dodajmy teraz nasz pierwszy własny tag.
W tym celu wywołujemy komendę:
git tag vX.X.1 e9e5ba39a78c8f5057262d49e261b42a8660d5b9
Czyli – w ogólnej postaci:
git tag <tag-name> <git-hash>
W historii commitów widzimy też, gdzie został dodany nasz nowy tag.
Dodawanie tagów do starych commitów (ang. tagging old commits)
Domyślnie – jeżeli nie wskażemy konkretnej zmiany w historii – git tworzy tag na commicie wskazywanym przez wskaźnik HEAD (czyli tym na samej górze w historii).
Jeżeli natomiast korzystamy z wersji z podaniem hasha commitu, to możemy wskazać praktycznie dowolną zmianę do oznaczenia.
Załóżmy na chwilę, że podczas tagowania historii – pomyliliśmy się 🤭
Albo lepiej – że zmieniliśmy zdanie – i teraz chcemy, żeby inny commit był oznaczony tym samym tagiem 😱
Jeżeli spróbujemy przepisać taki tag – czyli ustawić go w innym miejscu – to dostaniemy błąd w stylu: „fatal: tag 'vX.X.1′ already exists”.
Żeby móc przenieść istniejący tag w inne miejsce w historii – musimy dodać flagę -f (FORCE) – czyli wymusić taką operację.
Git checkout tag
Jeżeli mamy już dodany tag – to możemy podejrzeć stan repozytorium w tym punkcie w historii przy pomocy komendy:
git checkout <tag-name>
Taka komenda pozwoli nam podejrzeć stan repozytorium z tego punktu w historii – ale…
UWAGA!
Nasze repozytorium będzie teraz w dość specyficznym stanie. Wskaźnik HEAD jest odłączony (ang. detached HEAD state).
Możemy co prawda modyfikować stan repozytorium – ale nie zaktualizuje to naszego tagu. Zwyczajnie zostanie dodany nowy commit do historii i ten commit nie będzie przynależał ani do naszego tagu, ani do żadnego brancha i będzie dostępny tylko bezpośrednio po hashu.
Dlatego jeżeli chcemy coś tutaj zmieniać lepszym pomysłem będzie utworzenia brancha i później ewentualne przeniesienie tagu.
Żeby nie było zbyt prosto… 😉
Git wspiera dwa typy tagów:
- tagi adnotowane (ang. annotated tags)
- tagi lekkie (ang. lightweight tags)
Do tej pory korzystaliśmy z tak zwanych tagów lekkich.
Lightweight tags i annotated tags różnią się od siebie ilością przechowywanych dodatkowych meta danych.
Lekkie tagi jako te prostsze możemy porównać do swego rodzaju zakładek w historii. Przechowują tylko nazwę oraz wskaźnik na konkretny commit.
Bardzo dobrze się nadają kiedy chcemy szybko utworzyć jakiś link na konkretny commit, który będzie później tylko do naszego użytku.
Korzystając z operacji: git show możemy podejrzeć, na który commit wskazuje nasz tag.
Z drugiej strony tagi adnotowane przechowują dodatkowe meta dane, takie jak:
- nazwa oraz adres e-mail osoby tagującej,
- datę utworzenia tagu,
- oraz – analogicznie jak w przypadku commitów – wiadomość.
Takie informacje mogą być pomocne dla innych osób, dlatego z tagów adnotowanych (ang. annotated tags) korzystamy głównie przy współpracy z innymi.
Git showW przypadku tagu adnotowanego operacja:
git show <tag-name>
pokaże nie tylko informacje o samym commicie, na który wskazuje tag – ale również dodatkowe metadane z tagu.
Git push tag
Skoro wiemy już jak pracować z tagami w gicie lokalnie, to czas pokazać je światu.
Współdzielenie tagów działa bardzo podobnie do pracy z gałęziami. Domyślnie jednak operacja git push nie „wypcha” naszych tagów.
Żeby to zrobić, musimy jawnie wskazać nasz tag:
git push origin <tag-name>
Jeżeli chcemy natomiast wysłać do zdalnego repozytorium wszystkie tagi, możemy skorzystać z komendy:
git push --tags
W ty wypadku do zdalnego repozytorium wskazanego przez remote zostaną wysłane wszystkie tagi.
Git delete tagNa koniec jeszcze posprzątajmy po sobie – czyli usuńmy jeden z tagów.
O ile nasz tag jest dostępny tylko lokalnie – to wystarczy sama komenda:
git tag -d <tag-name>
Jeżeli jednak nasz tag został już wysłany do zdalnego repozytorium – musimy jeszcze wykonać dodatkową komendę:
git push --delete origin <tag-name>
W ramach tego materiału przećwiczyliśmy podstawową integrację gita z tagami.
Jeżeli chcesz kontynuować swoją przygodę z gitem – to zapraszam do dodatkowych materiałów:
➡ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone
20+ BONUSOWYCH materiałów z programowania
e-book – „8 rzeczy, które musisz wiedzieć, żeby dostać pracę jako programista”,
e-book – „Java Cheat Sheet”,
checklista – „Pytania rekrutacyjne”
i wiele, wiele wiecej!