Git tag
W tym dokumencie omówimy koncepcję tagowania w systemie Git oraz polecenie git tag. Tagi to odwołania wskazujące określone punkty w historii Git. Tagowanie zazwyczaj służy do oznaczenia punktu w historii stanowiącego podstawę opublikowanej wersji (np. v1.0.1).
Tag jest jak gałąź, która nie ulega zmianom. W przeciwieństwie do gałęzi tagi po utworzeniu nie mają dalszej historii commitów. Więcej informacji na temat gałęzi można znaleźć na stronie git branch.
Tutaj omówimy różne rodzaje tagów, sposób ich tworzenia, tworzenia wykazów, usuwania, udostępniania itd.
Tworzenie tagu
Aby utworzyć nowy tag, użyj następującego polecenia:
git tag <tagname>Zastąp < tagname > semantycznym identyfikatorem wskazującym stan repozytorium w momencie tworzenia tagu. Typowym rozwiązaniem jest użycie numerów wersji, np. git tag v1.4. Git obsługuje dwa typy tagów — adnotowane i lekkie. W poprzednim przykładzie utworzyliśmy tag lekki. Tagi lekkie i adnotowane różnią się ilością zawartych metadanych. Najlepszą praktyką jest uznanie tagów adnotowanych jako publicznych, a lekkich jako prywatnych. Tagi adnotowane zawierają dodatkowe metadane, takie jak nazwisko i e-mail twórcy oraz data utworzenia. To dane istotne dla wydania publicznego. Lekkie tagi są zasadniczo „zakładkami” do commitów; składają się wyłącznie z nazwy i odnośnika. Służą do tworzenia szybkich łączy do odpowiednich commitów.
Tagi adnotowane
Tagi adnotowane są przechowywane jako pełne obiekty w bazie danych Git. Jak wspomnieliśmy, zawierają dodatkowe metadane, takie jak nazwisko i e-mail twórcy oraz data utworzenia. Podobnie jak commity i komunikaty zatwierdzeń tagi adnotowane wiążą się z komunikatem tagowania. Dodatkowo, dla bezpieczeństwa, tagi adnotowane można podpisywać i weryfikować za pomocą GNU Privacy Guard (GPG). Sugerowaną najlepszą praktyką tagowania w systemie Git jest korzystanie z tagów adnotowanych, tak by mieć dostęp do wszystkich powiązanych metadanych.
git tag -a v1.4Wykonanie tego polecenia powoduje utworzenie nowego tagu adnotowanego oznaczonego numerem wersji 1.4. Polecenie następnie wywołuje skonfigurowany domyślny edytor tekstu oraz monit o dalsze wprowadzanie metadanych.
git tag -a v1.4 -m "my version 1.4"To polecenie przypomina poprzednie, ale ta wersja obejmuje opcję -m i komunikat. Jest to wygodny sposób, podobny do polecenia git commit -m, który powoduje natychmiastowe utworzenie tagu bez wywoływania lokalnego edytora tekstu; zamiast tego zapisany zostaje komunikat podany w ramach opcji -m.
materiały pokrewne
Git — ściągawka
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
Tagi lekkie
git tag v1.4-lwWykonanie tego polecenia powoduje utworzenie tagu lekkiego oznaczonego numerem wersji v1.4-lw. Tagi lekkie są tworzone, gdy nie ma opcji -a, -s ani -m. Tworzą nową sumę kontrolną tagu i zapisują ją w katalogu .git/ repozytorium projektu.
Wyświetlanie listy tagów
Aby wyświetlić listę tagów przechowywanych w repozytorium, wykonaj następujące czynności:
git tagSpowoduje to wyświetlenie listy tagów:
v0.10.0
v0.10.0-rc1
v0.11.0
v0.11.0-rc1
v0.11.1
v0.11.2
v0.12.0
v0.12.0-rc1
v0.12.1
v0.12.2
v0.13.0
v0.13.0-rc1
v0.13.0-rc2Do uszczegółowienia listy można użyć opcji -l z wzorcem wieloznacznym:
$ git tag -l *-rc*
v0.10.0-rc1
v0.11.0-rc1
v0.12.0-rc1
v0.13.0-rc1
v0.13.0-rc2
v0.14.0-rc1
v0.9.0-rc1
v15.0.0-rc.1
v15.0.0-rc.2
v15.4.0-rc.3W poprzednim przykładzie zastosowaliśmy opcję -l z wzorcem wieloznacznym -rc, która zwraca listę wszystkich tagów oznaczonych przedrostkiem -rc, zazwyczaj używanym do identyfikacji kandydatów do wydania.
Tagowanie starszych commitów
Poprzednie przykłady tagowania przedstawiały operacje na commitach niejawnych. Domyślnie polecenie git tag utworzy tag na commicie, do którego odniesienie znajduje się we wskaźniku HEAD. Zamiennie polecenie git tag można użyć jako odwołanie do określonego commitu. Spowoduje to otagowanie określonego commitu w miejsce domyślnego wskaźnika HEAD. Aby wyświetlić listę starszych commitów, wykonaj polecenie git log.
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'feature'
a6b4c97498bd301d84096da251c98a07c7723e65 add update method for thing
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'Użycie polecenia git log spowoduje wyświetlenie listy commitów. W tym przykładzie do utworzenia tagu wybierzemy pierwszy commit Merge branch 'feature'. Będziemy się musieli odnieść do hashu SHA commitu w celu przekazania systemowi Git:
git tag -a v1.2 15027957951b64cf874c3557a0f3547bd83b3ff6
Wykonanie powyższego wywołania git tag spowoduje utworzenie nowego commitu adnotowanego v1.2 dla commitu wybranego w poprzednim przykładzie polecenia git log.
Ponowne tagowanie / zastępowanie starszych tagów
W przypadku próby utworzenia tagu z istniejącym już identyfikatorem system Git wyświetli następujący błąd:
fatal: tag 'v0.4' already existsJeśli spróbujesz otagować starszy commit istniejącym identyfikatorem, Git wyświetli ten sam błąd.
W przypadku konieczności uaktualnienia istniejącego tagu należy użyć opcji -f FORCE.
git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6
Wykonanie powyższego polecenia zmapuje commit 15027957951b64cf874c3557a0f3547bd83b3ff6 do identyfikatora v1.4. Spowoduje to nadpisanie zawartości tagu v1.4.
Udostępnianie: wypychanie tagów do zdalnego repozytorium
Udostępnianie tagów przypomina wypychanie gałęzi. Domyślnie polecenie git push nie wypchnie tagów. Tagi muszą zostać jawnie przekazane do git push.
$ git push origin v1.4
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To git@bitbucket.com:atlasbro/gittagdocs.git
* [new tag] v1.4 -> v1.4Aby za jednym razem wypchnąć wiele tagów, należy przekazać opcję --tags do polecenia git push. Gdy inny użytkownik sklonuje lub pobierze repozytorium, otrzyma również nowe tagi.
Wyewidencjonowywanie tagów
Stan repozytorium można wyświetlić na podstawie tagu za pomocą polecenia git checkout.
git checkout v1.4Powyższe polecenie spowoduje wyewidencjonowanie tagu v1.4. Repozytorium zostanie ustawione w stanie odłączonego wskaźnika HEAD. Tag nie zostanie zatem uaktualniony o dokonane zmiany. Powstanie nowy, odłączony commit. Nowy, odłączony commit nie będzie częścią gałęzi i będzie dostępny tylko bezpośrednio za pośrednictwem hashu SHA commitu. Zaleca się zatem utworzenie nowej gałęzi za każdym razem, gdy są wprowadzane zmiany przy odłączonym wskaźniku HEAD.
Usuwanie tagów
Usuwanie tagów jest prostą operacją. Przekazanie opcji -d i identyfikatora tagu do polecenia git tag powoduje usunięcie wskazanego tagu.
$ git tag
v1
v2
v3
$ git tag -d v1
$ git tag
v2
v3W powyższym przykładzie zostaje zastosowane polecenie git tag — czego efektem jest wyświetlenie listy tagów zawierającej wersje v1, v2, v3 — a następnie polecenie git tag -d v1, które usuwa tag v1.
Podsumowanie
Podsumowując, tagowanie jest dodatkowym mechanizmem wykorzystywanym do tworzenia migawek repozytorium Git. Zazwyczaj tagowanie służy do tworzenia semantycznych identyfikatorów numerów wersji, które odpowiadają cyklom wydawania oprogramowania. Polecenie git tag oferuje główne funkcje w zakresie tagowania: tworzenie, modyfikację i usuwanie. Istnieją dwa rodzaje tagów: opisane i lekkie. Tagi opisane są na ogół lepszym rozwiązaniem, ponieważ zawierają dodatkowe cenne metadane. Ponadto w dokumencie tym omówiono polecenia git push i git checkout. Odwiedź powiązane strony, aby dowiedzieć się więcej o rodzajach zastosowań.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
