Git Tag

Git имеет возможность помечать определённые моменты в истории как важные. Как правило, эта функциональность используется для отметки моментов выпуска версий (v1.0, и т. п.). Такие пометки в Git называются тегами.

Создать тэг

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

По умолчанию ставиться на HEAD, но можем указать хэш коммита:

    git tag v0.0.1 d324c8dae
    // быстро перейти в состояние проекта версии v0.0.1
    git checkout  v0.0.1
    // если тег установлен после пуша, можно отправить в хранилище только тег
    git push origin v0.0.1
    To github.com:vadim-m/test-auto-tag.git
    * [new tag]         v0.0.1 -> v0.0.1
    // запушить все локальные теги
    git push origin --tags
    // удалить тег из хранилища github
    git push origin --delete v0.0.1
    To github.com:vadim-m/test-auto-tag.git
    - [deleted]         v0.0.3

После создания можно смотреть историю не по коммитам, а по тэгам:

    git show --quiet  v0.0.1
    // также тэги видно при просмотре git log
    git log --oneline
    // или так
    git log --pretty=oneline

tag-1.jpg

Виды тегов

Лёгкие теги

Представляют собой только ссылку на коммит. Создаются как выше (HEAD по умолчанию):

    git tag v0.0.2
    git log

tag-2.jpg

Теги с аннотацией

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

    git tag -a -m "Добавил github-action - Version 0.0.3" v0.0.3 d63f42
    // показать аннотированный тег
    git show v.0.0.3

tag-3.jpg

Маркировка релизов

Один из основных примеров использования тэгов в git - это маркировка релизов, чтобы чётко указать на каком коммите была выпущена определенная версия программы. Так как тэг является ссылкой на коммит и никуда не смещается при коммитах, это позволяет использовать его как неизменную метку, указывающую на "факт" выпуска определенной версии.

     // Можно начать новую ветку прямо с тэга для разработки новой версии
    git branch v0.0.2 v.0.0.1
    // Посмотреть все теги
    git tag 
    // Какие релизы содержат определенный коммит (по хэшу)
    git tag --contains d63f42
    // Вывести тег с сообщением коммита в одну строк
    git tag -n1
    // Вывести историю разработки с определенного тега
    git log --oneline v0.0.1
     // Вывести теги по маске
    git tag -n -l  "v0.0*"
    // Удалить теги
    git tag -d v0.0.3 v0.0.2 v.0.0.1

tag-4.jpg

Добавление авто-тегов при MR

В магазине Github Action есть специальный Github Tag Bump Action, цель которого - автоматическое повышении последней версии и добавление тега к коммиту ветки master при слиянии в формате SemVer. То есть при аппруве MR из другой ветки в master, происходит повышении (по умолчанию - MINOR) в автоматическом режиме.

Чтобы подключать данный action к проекту, нужно в скрытой папке .github/workflows проекта создать yaml-файл (github-actions.yaml), с текстовым описанием экшена:

name: Bump version
on:
  pull_request:
    types:
      - closed
    branches:
      - master

jobs:
  build:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-22.04
    permissions:
      contents: write
    steps:
    - uses: actions/checkout@v4
      with:
        ref: ${{ github.event.pull_request.merge_commit_sha }}
        fetch-depth: '0'

    - name: Bump version and push tag
      uses: anothrNick/github-tag-action@v1 # Don't use @master or @v1 unless you're happy to test the latest version
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # if you don't want to set write permissions use a PAT token
        WITH_V: true

Screenshot_%Y%M%D_%H.jpg

После добавления данного экшена основной flow работы с git становится следующим:

  1. Зафиксировать некоторые изменения в ветке (не master!)
  2. Запушить ветку в Github
  3. Открыть PR в master
  4. При слиянии будет получена последняя версия проекта и увеличена по правилам:
    • по умолчанию увеличивается minor-версия
    • если нужно увеличить major или patch нужно добавить флаги к сообщению коммита при слиянии #patch и #major

Пример с повышением patch-версии:

Screenshot_%Y%M%D_%H-4.jpg

Запуск джобы:

Screenshot_%Y%M%D_%H-5.jpg

Результат:

Screenshot_%Y%M%D_%H-6.jpg

Пример с повышением major-версии (внимание на отображение сообщения коммита):

Screenshot_%Y%M%D_%H-7.jpg

Screenshot_%Y%M%D_%H-8.jpg

Релизы

В Github есть функционал Releases для удобного распространения ПО.

Github releases — это развертываемые итерации программного обеспечения, которые можно упаковать и предоставить широкой аудитории для скачивания и использования. Выпуски основаны на тегах Git, которые отмечают определенную точку в истории репозитория. Дата тега может отличаться от даты выпуска, так как они могут быть созданы в разное время.

Ссылка на релизы помещена на главную страницу проекта. Зайдя в этот раздел, пользователь всегда может найти последнюю версию программы, changelog и полную историю версий. Вместе с каждым релизом публикуются текстовые примечания, ссылки на бинарный файл и исходный код.

В окне для создания нового релиза можно указать номер версии и описание релиза, можно присоединить отдельные файлы, можно выбрать тэг источник, а также предыдущий релизный тэг и, щелкнув на кнопку "Generate release notes", сгенерировать авто сравнение изменений.

Screenshot_%Y%M%D_%H-9.jpg

Screenshot_%Y%M%D_%H-10.jpg

Про тэги JavaScript.ru - youtube.com

Про тэги ADV-IT - youtube.com

Авто увелечение тега через Github Actions - github.com

How to Release Code With Github - youtube.com

Github Releases: публикация релизов - habr.com

Про Github Token - kobzarev.com

#ci/cd #git #github
openImgPic