Git tag
В этом документе описываются концепция использования тегов в Git и команда git tag. Теги — это ссылки, указывающие на определенные точки в истории Git. Команда git tag обычно используется для захвата некой точки в истории, которая используется для релиза нумерованной версии (например, v1.0.1).
Теги похожи на неизменяемые ветки, но они, в отличие от веток, не имеют истории коммитов после создания. Подробнее о ветках см. на странице, посвященной git branch.
В этом документе описываются различные виды тегов, способы их создания, просмотра, удаления, предоставления доступа к ним и многое другое.
Создание тега
Для создания нового тега выполните следующую команду:
git tag <tagname>Замените < имя_тега > семантическим идентификатором состояния репозитория на момент создания тега. Стандартный шаблон для указания номеров версий выглядит как git tag v1.4. Git поддерживает два типа тегов: аннотируемые и облегченные. В предыдущем примере был создан облегченный тег. Облегченные и аннотируемые теги отличаются объемом хранящихся в них сопутствующих метаданных. Рекомендуется рассматривать аннотируемые теги как открытые, а облегченные — как закрытые. В аннотируемых тегах хранятся дополнительные метаданные, такие как имя создателя тега, адрес электронной почты и дата. Это важные данные для версии общего пользования. Облегченные теги по сути являются «закладками» для коммитов. Это просто имя и указатель на коммит, что удобно для создания быстрых ссылок на соответствующие коммиты.
Аннотируемые теги
Аннотируемые теги хранятся в базе данных Git в виде полных объектов. Напомним, в них находятся дополнительные метаданные, такие как имя создателя тега, адрес электронной почты и дата. Аналогично комментариям к коммитам существуют комментарии к аннотируемым тегам. Кроме того, для обеспечения безопасности аннотируемые теги можно подписывать и проверять с помощью GNU Privacy Guard (GPG). Рекомендуется использовать аннотированные, а не облегченные теги, чтобы иметь доступ ко всем связанным метаданным.
git tag -a v1.4При выполнении этой команды будет создан аннотируемый тег с идентификатором v1.4. Затем команда откроет настроенный текстовый редактор по умолчанию, чтобы запросить ввод дальнейших метаданных.
git tag -a v1.4 -m "my version 1.4"Эта команда аналогична предыдущей, однако в этой версии передаются параметр -m и комментарий. Этот удобный способ похож на команду git commit -m, так как с его помощью новый тег создается без открытия локального текстового редактора. Вместо этого применяется комментарий, переданный после параметра -m.
Связанные материалы
Шпаргалка по Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
Облегченные теги
git tag v1.4-lwПри выполнении этой команды создается облегченный тег с идентификатором v1.4-lw. Облегченные теги создаются, когда не используются параметры -a, -s или -m. Этот тип тегов создает новую контрольную сумму тега и сохраняет ее в каталоге .git/ репозитория проекта.
Просмотр списка тегов
Чтобы просмотреть список сохраненных в репозитории тегов, выполните следующую команду.
git tagОна выведет список тегов:
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-rc2Чтобы уточнить список тегов, можно передать параметр -l и выражение с подстановочными знаками:
$ 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.3В указанном выше примере используются параметр -l и выражение с подстановочными знаками -rc, возвращающее список всех тегов с префиксом -rc, который обычно используется для обозначения предвыпускных релизов.
Применение тегов к старым коммитам
В предыдущих примерах использования тегов демонстрируются операции без указания коммита. По умолчанию команда git tag создает тег для коммита, на который ссылается указатель HEAD. Вместо этого в git tag можно передать ссылку на конкретный коммит. В этом случае тег будет создан для указанного коммита, а не для коммита, на который ссылается указатель HEAD. Чтобы просмотреть список предыдущих коммитов, запустите команду git log.
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'feature'
a6b4c97498bd301d84096da251c98a07c7723e65 add update method for thing
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'При выполнении команды git log будет выведен список коммитов. В этом примере мы создадим тег для самого верхнего коммита Merge branch 'feature'. Нам понадобится ссылка на SHA-хеш коммита, который мы передадим Git:
git tag -a v1.2 15027957951b64cf874c3557a0f3547bd83b3ff6
При выполнении приведенной выше команды git tag будет создан аннотируемый тег с идентификатором v1.2 для коммита, который мы выбрали в предыдущем примере с командой git log.
Переназначение тегов и замена старых тегов
Если вы попытаетесь создать тег с таким же идентификатором, как у существующего тега, Git выдаст ошибку, как показано ниже:
fatal: tag 'v0.4' already existsКроме того, если вы попытаетесь создать тег для старого коммита с существующим идентификатором тега, Git выдаст такую же ошибку.
Если вам необходимо обновить существующий тег, используйте параметр -f («force»).
git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6
Указанная выше команда сопоставит коммит 15027957951b64cf874c3557a0f3547bd83b3ff6 с идентификатором тега v1.4 и переопределит любой существующий контент для тега v1.4.
Публикация: отправка тегов в удаленный репозиторий
Публикация тегов похожа на отправку веток. По умолчанию команда git push не отправляет теги. Их необходимо указать в команде 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.4Для одновременной отправки сразу нескольких тегов необходимо указать в команде git push параметр --tags. Когда другие пользователи будут клонировать репозиторий или выполнять для репозитория команду pull, они получат новые теги.
Переключение тегов
Просмотреть состояние репозитория по тегу можно с помощью команды git checkout.
git checkout v1.4Указанная выше команда выполнит переход к тегу v1.4. При этом репозиторий перейдет в состояние открепленного указателя HEAD. Это значит, что любые внесенные изменения не будут добавлены в этот тег. Они попадут в новый открепленный коммит, который не будет принадлежать ни к какой ветке, и перейти на него можно будет только напрямую по SHA-хешу этого коммита. Поэтому рекомендуется создавать новую ветку каждый раз, когда вы вносите изменения, находясь в состоянии открепленного указателя HEAD.
Удаление тегов
Удаление тегов — довольно простая операция. Чтобы удалить определенный тег, передайте команде git tag параметр -d и идентификатор этого тега.
$ git tag
v1
v2
v3
$ git tag -d v1
$ git tag
v2
v3В этом примере при выполнении команды git tag отобразился список тегов: v1, v2, v3. Затем была запущена команда git tag -d v1, которая удалила тег v1.
Резюме
Итак, теги — это дополнительный механизм для создания снимков состояния репозитория Git. Обычно теги используются для создания семантических идентификаторов номера версии, которые соответствуют циклам релизов программного обеспечения. Для создания, изменения и удаления тегов используется команда git tag. Существует два типа тегов: аннотированные и легковесные. Обычно рекомендуется использовать аннотированные теги, поскольку в них хранятся дополнительные важные метаданные об этих тегах. В этом документе также упоминаются и другие команды Git: git push и git checkout. Подробную информацию об их использовании см. на соответствующих страницах.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.
Блог Bitbucket
Образовательные программы DevOps
