Как получить последнее имя тега в текущей ветке в Git?

Question

Какой самый простой способ получить самый последний тег в Git?

git tag a HEAD
git tag b HEAD^^
git tag c HEAD^
git tag

выход:

a
b
c

Должен ли я написать скрипт для получения даты и времени каждого тега и сравнения их?

Answer 1

Чтобы получить самый последний тег:

git describe --tags

Чтобы получить самый последний аннотированный тег:

git describe --abbrev=0

Answer 2

Вы можете взглянуть на git describe, что делает что-то близкое к тому, что вы просите.

Answer 3

Выводит тег последней отмеченной фиксации во всех ветвях

git describe --tags $(git rev-list --tags --max-count=1)

Answer 4

Чтобы получить самый последний тег, вы можете сделать:

$ git for-each-ref refs/tags --sort=-taggerdate --format='%(refname)' --count=1

Конечно, вы можете изменить аргумент count или поле сортировки по своему усмотрению. Кажется что вы, возможно, хотели задать немного другой вопрос, но это действительно ответ на вопрос, как я его понимаю.

Answer 5

Как насчет этого?

TAG=$(git describe $(git rev-list --tags --max-count=1))

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

Answer 6

git describe --tags

возвращает последний тег, видимый текущей веткой

Answer 7

«Самый последний» может иметь два значения в терминах git.

Вы могли бы иметь в виду, «какой тег имеет дату создания, наиболее позднюю по времени», и большинство ответов здесь относятся к этому вопросу. С точки зрения вашего вопроса, вы хотели бы вернуть тег c.

Или вы можете указать "какой тег является самым близким в истории разработки к некоторой именованной ветви", обычно это ветвь, в которой вы находитесь, HEAD. В вашем вопросе это вернет тег a.

Конечно, они могут отличаться:

A->B->C->D->E->F (HEAD)
       \     \
        \     X->Y->Z (v0.2)
         P->Q (v0.1)

Представьте, что разработчик пометил Z как v0.2 в понедельник, а затем пометил Q как v0.1 во вторник. v0.1 более поздний, но v0.2 в истории разработки ближе к HEAD, в том смысле, что путь, по которому он идет, начинается в точке, ближе к HEAD.

Я думаю, вы обычно хотите этот второй ответ, ближе к истории развития. Вы можете узнать это, используя git log v0.2..HEAD и т. Д. Для каждого тега. Это дает вам количество коммитов на HEAD, поскольку путь, заканчивающийся на v0.2, отличается от пути, на который следует HEAD.

Вот скрипт Python, который делает это путем итерации всех тегов, выполняющих эту проверку, а затем распечатывает тег с наименьшим количеством фиксаций в HEAD, поскольку путь тега расходится:

https://github.com/MacPython/terryfy/blob/master/git-closest-tag

git describe делает что-то немного другое, в том смысле, что он отслеживает (например,) HEAD, чтобы найти первый тег, который находится на пути назад в истории из HEAD. С точки зрения git, git describe ищет теги, которые «достижимы» из HEAD. Поэтому он не найдет теги типа v0.2, которые находятся не на пути назад от HEAD, а на пути, который расходится оттуда.

Answer 8

Вы можете выполнить: git describe --tags $(git rev-list --tags --max-count=1) говорили здесь: Как получить последнее имя тега?

Answer 9

git log --tags --no-walk --pretty="format:%d" | sed 2q | sed 's/[()]//g' | sed s/,[^,]*$// | sed  's ......  '

ЕСЛИ ВАМ НУЖНО БОЛЬШЕ, ЧЕМ ОДИН ПОСЛЕДНИЙ ТЕГ

(git description --tags иногда дает неправильные хэши, я не знаю почему, но для меня --max-count 2 не работает)

это то, как вы можете получить список с двумя последними именами тегов в обратном хронологическом порядке, отлично работает на git 1.8.4. Для более ранних версий git (например, 1.7. *) В выводе нет строки «tag:» - просто удалите последний вызов sed

Если вы хотите более 2 последних тегов - измените это «sed 2q» на «sed 5q» или что вам нужно

Тогда вы можете легко разобрать каждое имя тега в переменную или около того.

Answer 10

Что не так со всеми предложениями (кроме Мэттью Бретт объяснение, до даты публикации этого ответа)?

Просто запустите любую команду, предоставленную другим, в истории jQuery Git, когда вы находитесь в другой точке истории и проверьте результат с помощью визуального представления истории тегов (I did вот почему вы видите этот пост):

$ git log --graph --all --decorate --oneline --simplify-by-decoration

Сегодня многие проекты выполняют релизы (и т. Д.) в отдельной ветке от основной линии .

Для этого есть веская причина . Просто посмотрите на любые хорошо зарекомендовавшие себя проекты JS / CSS. Для пользовательских соглашений они несут двоичные / минимизированные файлы выпуска в DVCS. Естественно, как сопровождающий проекта вы не хотите очищать свою основную историю diff от бесполезных двоичных двоичных объектов и выполнять фиксацию артефактов сборки из основной линии .

Поскольку Git использует DAG, а не линейную историю - трудно определить метрику расстояния , поэтому мы можем сказать - о, эта скорость наиболее близка к моей HEAD!

Я начинаю свое собственное путешествие (загляните внутрь, я не скопировал причудливые пробные изображения в этот длинный пост):

Какой ближайший тег в прошлом относился к ветвлению в Git?

В настоящее время у меня есть 4 разумных определения расстояния между тегом и ревизией с уменьшением полезности:

• длина кратчайшего пути от HEAD до объединение базы с тегом
• дата из объединить базу между HEAD и тегом
• количество оборотов , которые достижимы из HEAD, но недоступны из тега
• дата тега независимо база слияния

Я не знаю, как рассчитать длину кратчайшего пути .

Скрипт, который сортирует теги по дате из базы слияния между HEAD и тегом:

$ git tag \
     | while read t; do \
         b=`git merge-base HEAD $t`; \
         echo `git log -n 1 $b --format=%ai` $t; \
       done | sort

Используется в большинстве проектов.

Скрипт, который сортирует теги в соответствии с числом оборотов , которые доступны из HEAD, но недоступны из тега:

$ git tag \
    | while read t; do echo `git rev-list --count $t..HEAD` $t; done \
    | sort -n

Если в истории вашего проекта есть странные даты коммитов (из-за перебазировок или другой перезаписи истории, или какой-то придурок забыл заменить батарею BIOS или другую магию, которую вы делаете в истории), используйте сценарий выше.

Для последнего варианта ( дата тега независимо объединить базу ) для получения списка тегов, отсортированных по дате, используйте:

$ git log --tags --simplify-by-decoration --pretty="format:%ci %d" | sort -r

Чтобы узнать текущую дату ревизии, используйте:

$ git log --max-count=1

Обратите внимание, что git describe --tags используется в своих собственных случаях, но не для поиска ожидаемого человеком ближайшего тега в истории проекта .

ПРИМЕЧАНИЕ Вы можете использовать вышеуказанные рецепты в любой ревизии, просто замените HEAD на то, что вы хотите!