Pokaż, który tag git używasz?

216

Mam problem ze znalezieniem, który tag jest obecnie sprawdzony.

Kiedy robię:

git checkout tag1
git branch

Nie mogę się dowiedzieć, na którym znaczniku jestem. Rejestruje tylko:

* (no branch)
master

Czy można dowiedzieć się, które tagi są sprawdzane? W powyższym przykładzie byłoby to tag1.

git git-checkout git-tag

— grm
źródło

326

Edytuj : Jakub Narębski ma więcej git-fu. Następujące znacznie prostsze polecenie działa idealnie:

git describe --tags

(Lub bez, --tagsjeśli sprawdziłeś tag z adnotacjami. Mój tag jest lekki, więc potrzebuję --tagów).

oryginalna odpowiedź brzmi:

git describe --exact-match --tags $(git log -n1 --pretty='%h')

Ktoś z większą ilością git-fu może mieć bardziej eleganckie rozwiązanie ...

Wykorzystuje to fakt, że git-lograportowanie dziennika rozpoczyna się od tego, co sprawdziłeś. %hdrukuje skrót skrótu. Następnie git describe --exact-match --tagsznajduje znacznik (lekki lub z adnotacjami), który dokładnie pasuje do tego zatwierdzenia.

Powyższa $()składnia zakłada, że używasz bash lub podobnego.

— bstpierre
źródło

22

Tylko użycie git describespowoduje wyświetlenie nazwy znacznika, jeśli jesteś dokładnie na (opatrzony adnotacjami) znaczniku, a <tag>-<n>-g<shortened sha-1>jeśli nie, gdzie <n>jest liczba zatwierdzeń od tego czasu <tag>.

— Jakub Narębski,

1

@Jakub - Dzięki. Dodałem --exact-matchdo mojej odpowiedzi sekundy przed twoim komentarzem. Miło wiedzieć, że można go usunąć i nadal uzyskiwać dobre informacje z wejścia bardziej rozwścieczonego.

— bstpierre

Dzięki, właśnie tego szukałem. Btw, nawet git-description --exact-match (bez --tags) działa dla mnie.

— grm

3

Użycie git rev-parse HEADjest lepszym rozwiązaniem niż git log -n1 --pretty='%h'... ale dlaczego nie możesz po prostu pisać HEAD(lub nic, jak git describedomyślnie HEAD)?

— Jakub Narębski,

tylko Guybrush nienawidzi porcelany

— vdegenne

71

To zadziałało dla mnie git describe --tags --abbrev=0

— MK
źródło

2

Tak. działa to nawet, jeśli nie jesteś dokładnie na tym tagu! :)

— Martin Muzatko

13

Uhhh ... Jeśli wyewidencjonujesz skrót trzy zatwierdzenia po znaczniku, nie będziesz „na tym znaczniku”. Mówi ci ostatni tag przed lub przy zatwierdzonym sprawdzeniu. To jest niepoprawne.

— ingyhere

Działa również w systemie Windows :)

— cowlinator

50

Pokaż wszystkie tagi na bieżącym HEAD (lub zatwierdzeniu)

git tag --points-at HEAD

— George Pavelka
źródło

1

Zauważ, że to polecenie nie zgłasza błędu w wierszu polecenia, nawet jeśli wynik jest pusty. Pluskwa? Zwraca również listę, jeśli w tej lokalizacji znajduje się wiele tagów. To najlepsza odpowiedź, ale scenarzyści powinni zachować ostrożność, pamiętając o tych zastrzeżeniach.

— ingyhere

Po komentarzu @ ingyhere. Tak, to dobra informacja, że nie ma błędu i ludzie muszą odpowiednio traktować wynik. Ale nie nazwałbym tego błędem. W moim przypadku „puste, jeśli nie ma tagów” jest prawidłowe. Inne przypadki, ktoś może zapisać go do zmiennej, a następnie sprawdzić, czy jest ona pusta (link do instrukcji bash)

— driftcatcher

23

git describeto polecenie porcelany , którego należy unikać:

http://git-blame.blogspot.com/2013/06/checking-current-branch-programatically.html

Zamiast tego użyłem:

git name-rev --tags --name-only $(git rev-parse HEAD)

— Greg
źródło

11

Powraca „niezdefiniowany”

— Stranger

4

Powoduje to, że końcowe ^0dla zatwierdzeń, które odpowiadają znacznikom (np. Dla danych 1.0wyjściowych znacznika it 1.0^0). Czy jest jakiś sposób, aby mieć tylko wyjście Git 1.0, czy powinienem do tego użyć sed?

— Daniel Serodio

13

Tylko trochę pojęciowego nitpikingu: myślę, że odwróciłeś znaczenie porcelany i hydrauliki. Można używać porcelany, jest na wysokim poziomie i przeznaczona do normalnego użytku . Instalacja hydrauliczna jest wewnętrzna (jak sama nazwa wskazuje) i nie jest zalecana, ponieważ programiści git zastrzegają sobie prawo do zmiany argumentów i wyników bez ostrzeżenia. Więc twoja pierwsza sugestia jest właściwie nieco bardziej odpowiednia.

— Leo Antunes,

5

Artykuł z linkami mówi, aby unikać używania „gałęzi git”, ponieważ nie działa w tym przypadku użycia. Nie mogę wymyślić żadnego dobrego powodu, aby unikać używania git description. Jak mówi Leo, polecenia „Porcelana” to polecenia, których zwykle należy używać. Unikaj poleceń hydraulicznych, chyba że naprawdę wiesz, co robisz. „git opisz” działa świetnie.

— Danny

4

Polecenia „Porcelana” to te, których powinieneś używać, a nie te, których powinieneś unikać. Są to polecenia, których dane wyjściowe można odczytać maszynowo i nie zmienią się w przyszłych wersjach, więc można na nich polegać w skryptach itp. Polecenia nie porcelanowe mają tendencję do generowania wyników bardziej czytelnych dla człowieka, ale mogą ulec zmianie w przyszłych wersjach, np. Aby zwiększyć czytelne, nie dlatego, że coś ważnego się zmieniło.

— rjmunro

22

Kiedy sprawdzasz tag, masz tak zwaną „odłączoną głowę” . Zwykle zatwierdzenie HEAD Gita jest wskaźnikiem do gałęzi, którą aktualnie wypisałeś. Jeśli jednak wypisujesz coś innego niż gałąź lokalna (na przykład tag lub gałąź zdalna), masz „odłączoną głowę” - tak naprawdę nie jesteś w żadnej gałęzi. Nie powinieneś dokonywać żadnych zatwierdzeń, gdy jesteś na odłączonej głowie.

Sprawdzanie tagu jest w porządku, jeśli nie chcesz wprowadzać żadnych zmian. Jeśli tylko badasz zawartość plików lub chcesz zbudować swój projekt na podstawie znacznika, możeszgit checkout my_tag z nimi pracować i pracować z nimi, o ile nie popełnisz żadnych zmian . Jeśli chcesz rozpocząć modyfikowanie plików, powinieneś utworzyć gałąź na podstawie znacznika:

$ git checkout -b my_tag_branch my_tag

utworzy nowy oddział o nazwie my_tag_branchzaczynając od my_tag. Zmiany w tej gałęzi są bezpieczne.

— mipadi
źródło

1

Fantastyczna odpowiedź.

— Panos Filianos

9

git log --decorate

Dzięki temu dowiesz się, jakie referencje wskazują na aktualnie sprawdzone zatwierdzenie.

— chriswatrous
źródło