Git tag
В этом документе описываются концепция использования тегов в Git и команда git tag
. Теги — это ссылки, указывающие на определенные точки в истории Git. Команда git tag обычно используется для захвата некой точки в истории, которая используется для релиза нумерованной версии (например, v1.0.1). Теги похожи на неизменяемые ветки, но они, в отличие от веток, не имеют истории коммитов после создания. Подробнее о ветках см. на странице, посвященной git branch
. В этом документе описываются различные виды тегов, способы их создания, просмотра, удаления, предоставления доступа к ним и многое другое.
Создание тега
Для создания нового тега выполните следующую команду:
git tag <tagname>
Замените < имя_тега >
семантическим идентификатором состояния репозитория на момент создания тега. Стандартный шаблон для указания номеров версий выглядит как git tag v1.4
. Git поддерживает два типа тегов: аннотируемые и облегченные. В предыдущем примере был создан облегченный тег. Облегченные и аннотируемые теги отличаются объемом хранящихся в них сопутствующих метаданных. Рекомендуется рассматривать аннотируемые теги как открытые, а облегченные — как закрытые. В аннотируемых тегах хранятся дополнительные метаданные, такие как имя создателя тега, адрес электронной почты и дата. Это важные данные для версии общего пользования. Облегченные теги по сути являются «закладками» для коммитов. Это просто имя и указатель на коммит, что удобно для создания быстрых ссылок на соответствующие коммиты.
Annotated tags
Аннотируемые теги хранятся в базе данных 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
Lightweight tags
git tag v1.4-lw
При выполнении этой команды создается облегченный тег с идентификатором v1.4-lw
. Облегченные теги создаются, когда не используются параметры -a
, -s
или -m
. Этот тип тегов создает новую контрольную сумму тега и сохраняет ее в каталоге .git/
репозитория проекта.
Listing tags
Чтобы просмотреть список сохраненных в репозитории тегов, выполните следующую команду.
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
, который обычно используется для обозначения предвыпускных релизов.
Tagging old commits
В предыдущих примерах использования тегов демонстрируются операции без указания коммита. По умолчанию команда 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
.
ReTagging/Replacing old tags
Если вы попытаетесь создать тег с таким же идентификатором, как у существующего тега, Git выдаст ошибку, как показано ниже:
fatal: tag 'v0.4' already exists
Кроме того, если вы попытаетесь создать тег для старого коммита с существующим идентификатором тега, Git выдаст такую же ошибку.
Если вам необходимо обновить существующий тег, используйте параметр -f
(«force»).
git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6
Указанная выше команда сопоставит коммит 15027957951b64cf874c3557a0f3547bd83b3ff6
с идентификатором тега v1.4
и переопределит любой существующий контент для тега v1.4
.
Sharing: Pushing tags to remote
Публикация тегов похожа на отправку веток. По умолчанию команда 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, они получат новые теги.
Checking out tags
You can view the state of a repo at a tag by using the git checkout command.
git checkout v1.4
Указанная выше команда выполнит переход к тегу v1.4
. При этом репозиторий перейдет в состояние открепленного указателя HEAD
. Это значит, что любые внесенные изменения не будут добавлены в этот тег. Они попадут в новый открепленный коммит, который не будет принадлежать ни к какой ветке, и перейти на него можно будет только напрямую по SHA-хешу этого коммита. Поэтому рекомендуется создавать новую ветку каждый раз, когда вы вносите изменения, находясь в состоянии открепленного указателя HEAD
.
Deleting tags
Удаление тегов — довольно простая операция. Чтобы удалить определенный тег, передайте команде 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.
Резюме
To recap, Tagging is an additional mechanism used to create a snap shot of a Git repo. Tagging is traditionally used to create semantic version number identifier tags that correspond to software release cycles. The git tag
command is the primary driver of tag: creation, modification and deletion. There are two types of tags; annotated and lightweight. Annotated tags are generally the better practices as they store additional valuable meta data about the tag. Additional Git commands covered in this document were git push, and git checkout. Visit their corresponding pages for discussion on their extended use.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.

Блог Bitbucket

Образовательные программы DevOps
