Показать, на какой метке git вы находитесь?

216

У меня проблемы с поиском, какой тег в настоящее время извлечен.

Когда я делаю:

git checkout tag1
git branch

Кажется, я не могу узнать, на каком теге я нахожусь. Это только логи:

* (no branch)
master

Можно ли узнать, какие теги проверены? В приведенном выше примере это будет tag1.

git git-checkout git-tag

— грм
источник

326

Редактировать : у Якуба Наренбского больше гитфу. Следующая намного более простая команда работает отлично:

git describe --tags

(Или без, --tagsесли вы отметили аннотированный тег. Мой тег облегчен, поэтому мне нужны --tags.)

оригинальный ответ следует:

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

У кого-то с большим количеством мерзавца может быть более изящное решение ...

Это использует тот факт, что git-logотчеты о журнале, начиная с того, что вы извлекли. %hпечатает сокращенный хеш Затем git describe --exact-match --tagsнаходит тег (легкий или аннотированный), который точно соответствует этому коммиту.

$()Синтаксис выше , предполагает , что вы используете Баш или аналогичный.

— bstpierre
источник

22

Простое использование git describeпокажет имя тега, если вы находитесь на (аннотированном) теге, или, <tag>-<n>-g<shortened sha-1>если нет, то где <n>число подтверждений с тех пор <tag>.

— Якуб Наребски

1

@Jakub - Спасибо. Я добавил --exact-matchк своему ответу секунды до вашего комментария. Приятно знать, что вы можете удалить его и получить полезную информацию из нечеткого ввода.

— Bstpierre

Спасибо, это именно то, что я искал. Кстати, даже git-description --exact-match (без --tags) работает для меня.

— гр

3

Использование git rev-parse HEAD- лучшее решение, чем git log -n1 --pretty='%h'... но почему вы не можете просто написать HEAD(или ничего, по git describeумолчанию HEAD)?

— Якуб Наребски

только Гайбраш ненавидит фарфор

— vdegenne

71

Это сработало для меня git describe --tags --abbrev=0

— MK
источник

2

Да. это работает, даже если вы не совсем на этом теге! :)

— Мартин Музатко

13

Уххй. ... Если вы извлекаете хэш из трех коммитов после тега, вы не «в этом теге». Он сообщает вам последний тег перед или при подтверждении коммита. Так что это неверно.

— августа

Работает и на Windows :)

— cowlinator

51

Показать все теги на текущем заголовке (или коммите)

git tag --points-at HEAD

— Георгий Павелка
источник

1

Обратите внимание, что эта команда не сообщает об ошибке в командной строке, даже если результат появляется пустым. Ошибка? Он также возвращает список, если в этом месте есть несколько тегов. Это лучший ответ, но авторы должны действовать с осторожностью, помня об этих предостережениях.

— августа

После комментария @ ingyhere. Да, это хорошая информация, что в ней нет ошибки, и люди должны соответственно обработать результат. Но я бы не назвал это ошибкой. В моем случае «пусто, если нет тегов» является действительным. В других случаях кто-то может сохранить его в переменной, а затем проверить, не является ли он пустым (ссылка на инструкции bash)

— driftcatcher

23

git describeэто фарфоровая команда, которую вы должны избегать:

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

Вместо этого я использовал:

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

— Greg
источник

11

Возвращается «неопределенный»

— незнакомец

4

Это выводит трейлинг ^0для коммитов, которые соответствуют тэгам (например, для тэгов, которые 1.0он выводит 1.0^0). Есть ли способ получить только вывод Git 1.0, или я должен использовать sed для этого?

— Даниэль Серодио

13

Просто немного концептуальной придирки: я думаю, что вы перевернули значения фарфора и сантехники. Можно использовать фарфор, он высокого уровня и предназначен для нормального использования . Сантехника внутренняя (как следует из названия) и только не рекомендуется, поскольку разработчики git оставляют за собой право изменять свои аргументы и вывод без предупреждения. Таким образом, ваше первое предложение на самом деле является более подходящим.

— Лев Антунес

5

В связанной статье говорится, что следует избегать использования «git branch», потому что это не работает для этого варианта использования. Я не могу придумать вескую причину, чтобы не использовать git description. Как говорит Лео, «фарфоровые» команды - это команды, которые вы обычно должны использовать. Избегайте сантехнических команд, если вы действительно не знаете, что делаете. "Git Description" прекрасно работает.

— Дэнни

4

«Фарфоровые» команды - это те, которые вы должны использовать, а не те, которых вам следует избегать. Это команды, чей вывод является машиночитаемым и не изменится в будущих версиях, поэтому на них можно положиться в сценариях и т. Д. Не фарфоровые команды, как правило, производят более читабельный вывод, но могут измениться в будущих версиях, например, сделать его более удобочитаемо, а не потому, что что-то важное действительно изменилось.

— rjmunro

22

Когда вы проверяете тег, у вас есть то, что называется «оторванная голова» . Обычно коммит Git HEAD - это указатель на ветку, которую вы в данный момент извлекли. Однако, если вы извлекаете что-то, кроме локальной ветки (например, тег или удаленную ветку), у вас есть «оторванная голова» - вы не находитесь ни в одной ветке. Вы не должны совершать какие-либо коммиты, находясь на отстраненной голове.

Можно проверить тег, если вы не хотите вносить какие-либо изменения. Если вы просто просматриваете содержимое файлов или хотите построить свой проект из тега, то все в порядке git checkout my_tagи работайте с файлами, если вы не делаете никаких коммитов . Если вы хотите начать изменять файлы, вы должны создать ветку на основе тега:

$ git checkout -b my_tag_branch my_tag

создаст новую ветку с именем, my_tag_branchначиная с my_tag. В этой ветке безопасно вносить изменения.

— mipadi
источник

1

Фантастический ответ.

— Панос Филианос

9

git log --decorate

Это скажет вам, какие ссылки указывают на текущий извлеченный коммит.

— chriswatrous
источник