Znowu po sporej przerwie, ale za to z ciekawostkami na poprawę wrażenia. Hehe, a tak na serio czeka Was parę minut lektury nt. korzystania ze znaczników (inaczej etykiet, tagów) w repozytorium. Po „głównym daniu” zaserwuję deser, który to tak naprawdę skłonił mnie do zamieszczenia tego wpisu.

Etykiety w repozytorium

Temat powinien być znany wszystkim korzystającym z repozytoriów GIT. Stosowane są one przede wszystkim do:

• wersjonowania aplikacji
• określania rewizji na indywidualne potrzeby (np. wdrożenie na określony serwer

Należy pamiętać, by stosować etykiety, kiedy niewymagane jest tworzenie gałęzi. Jak się domyślacie, odpowiedzialność etykiet można przenieść na gałęzie, ale wtedy będziemy zaśmiecać repozytorium w zastraszającym tempie. Nie jest to nam do niczego potrzebne.

Znaczniki dzielą się na lekkie i oznaczone. Lekkie posiadają wyłącznie skrót rewizji, natomiast oznaczone rozszerzone są o autora, datę utworzenia i ewentualny komentarz.

 

Tworzenie

git tag -a nazwa_taga -m "Opis taga - opcjonalny" skrót_rewizji_wskazującej

Każdy nowy tag musi być opatrzony unikalną nazwą, co nie powinno specjalnie dziwić. Znaczniki są bowiem aliasami dla rewizji na którą wskazują.

 

Listowanie tagów

git tag

Powyższą komendą wyświetlimy wszystkie tagi, które do tej pory zostały utworzone w repozytorium.

git describe --tags

Teraz z kolei dowiemy się jakie jest najmłodszy znacznik (alias dotyczący najmłodszej rewizji).

 

Wypychanie tagów

Czynność trywialnie prosta:

git push --tags

 

Znaczniki opisane są obiektami zapisanymi w bazie danych .git w postaci rewizji. Znaczniki lekkie są zapisane w plikach tekstowych w folderze .git/refs/tags.

„Git. Rozproszony system kontroli wersji” – W. Gajda

 

Czas na deser

Niedawno musiałem się zmierzyć z pewnym problemem. Otóż utworzyłem sobie tag o identycznej nazwie jak nazwa gałęzi. O ile do tego momentu na repozytorium pracowało się bezproblemowo, o tyle odtąd nie mogłem wypchnąć zmian (commit’ów).

Z pomocą przychodzi dokumentacja Gita. Wyczytamy tam kilka przydatnych informacji, jak chociażby te dotyczące parametru <refspec>.

Parametr ten ma może przyjąć postać <src>:<dst>, co już jest dla nas zrozumiałe. Jedyną przeszkodą może być postać ścieżki źródłowej i docelowej. Chodzi o ścieżki pozwalającej zidentyfikować źródło i element docelowy w bazie Git i tyle.

Zmiany wówczas można wypchnąć przez komendę:

git push origin refs/heads/nazwa_gałęzi:refs/heads/nazwa_gałęzi 

Ok, ale nawet dodanie parametru śledzenia gałęzi (-u) nie rozwiąże problemu na przyszłość. Wymagane jest puszowanie w tym przypadku wyłącznie z wykorzystaniem w/w komendy. Uciążliwość – nie jest to warte czasu poświęconego na dukanie komendy przed każdym wypychaniem zmian. (Szczerze nawet nie sprawdzałem jakie jest zachowanie przy pobieraniu zmian z repozytorium zdalnego, ale sądzę, że problem może być podobny. Dokumentacja komendy git pull również przewiduje <refspec>.)

Osobiście polecam nie popełniać błędu nazywania znacznika przez nazwę występującej gałęzi. Tylko kłopoty z tego. W takiej sytuacji proponuję zmianę nazwy etykiety:

git tag new old
git tag -d old
git push origin :refs/tags/old
git push --tags

Trzecia komenda z powyższych musi zostać wykonana w przypadku wypchnięcia do serwera zdalnego wadliwego znacznika. Powoduje ona usunięcie tego znacznika właśnie serwera zdalnego.

Uwaga! Jeśli wadliwy znacznik został już pobrany na lokalne instancje osób współdzielących repozytorium wymagane jest wywołanie u nich komendy:

git pull --prune --tags

O parametrze prune możecie doczytać tutaj.

 

Przesuwanie znaczników

Zdarza się, że źle ustawiliśmy znacznik lub celowo chcemy go przesunąć, by spełniał swoje zadanie. Nic trudnego.

git tag -fa nazwa_taga skrót_rewizji_wskazującej
git push -f --tags

Parametr -f w obu przypadkach możemy zastąpić przez –force, gdyż są one tożsame. Parametr -a z pierwszej komendy możemy usunąć, gdy polecenie nie dotyczy etykiety opisanej (gdy dotyczy etykiety lekkiej).

 

Dziękuję za uwagę. Pozdrawiam!