Close

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
СМ. РЕШЕНИЕ

Изучите 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

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

Демонстрация функций в демо-зале с участием экспертов Atlassian

Как инструмент Bitbucket Cloud работает с Atlassian Open DevOps

Подпишитесь на информационную рассылку по DevOps

Thank you for signing up