git-release-tag — Релизный semver-тег с changelog

Цель: одной операцией провести релиз — определить версию, собрать changelog, поставить тег, при желании запушить.

Перед началом прочитай ../../rules/git-conventions.md — разделы про Semver и теги.

Шаг 1. Определи контекст репозитория

• монорепо с несколькими SDK или одиночный пакет?
  • одиночный → v<X>.<Y>.<Z>, работаешь дальше по этому скиллу
  • монорепо → теги вида <sdk>/v<X>.<Y>.<Z> (например, sdk-go/v0.3.1)
• если монорепо и пакет для релиза ещё не выбран — это работа git-monorepo-release: он определит состав релиза и вызовет этот скилл на каждый тег. Если тебя вызвали уже с конкретным пакетом — продолжай, тег будет <sdk>/v<X>.<Y>.<Z>

Найди последний тег:

git tag --list 'v*' --sort=-v:refname | head -5            # одиночный
git tag --list 'sdk-go/v*' --sort=-v:refname | head -5     # пер-SDK

Если тегов нет — стартуй с v0.1.0 (или <sdk>/v0.1.0).

Шаг 2. Собери коммиты с прошлого тега

git log <last-tag>..HEAD --oneline
git log <last-tag>..HEAD --pretty=format:'%h %s%n%b%n'

В монорепо отфильтруй коммиты, затрагивающие нужный SDK:

git log <last-tag>..HEAD -- sdk-go/

Шаг 3. Определи bump

Проанализируй коммиты:

Если коммиты не по конвенции — покажи их пользователю и спроси, какой bump.

Шаг 4. Сформируй changelog

Группируй коммиты по type. Формат:

## v0.4.0 — 2026-05-23

### Breaking changes
- <commit subject> (`<sha>`)

### Features
- feat(scope): <subject> (`<sha>`)

### Fixes
- fix(scope): <subject> (`<sha>`)

### Other
- refactor / docs / chore — кратко

<полная дельта: git log link>

Шаг 5. Покажи и подтверди

Покажи:

• предлагаемую версию (v0.4.0)
• changelog
• команды, которые будут выполнены

Спроси:

1. Принять и поставить тег локально
2. Принять + push в origin
3. Поправить версию вручную
4. Поправить changelog
5. Отменить

Шаг 6. Выполни

После подтверждения:

# annotated tag с changelog в сообщении
git tag -a <tag> -m "$(cat <<'EOF'
<changelog>
EOF
)"

# или с push:
git push origin <tag>

Не пушь без явного подтверждения. Тег в публичный repo — это операция, которую сложно откатить (особенно если на тег уже подписана CI/release-pipeline).

Шаг 7. Опубликуй release (опционально)

Если есть gh CLI и пользователь хочет публичный release с notes:

gh release create <tag> --notes-file <changelog.md> --title "<tag>"

Чего не делать

• Не удаляй и не передвигай существующие теги (git tag -d, git push --delete) без явного запроса
• Не бамьпай major на свежем feat: если в нём нет breaking change
• Не повторно используй версию, которая уже была опубликована
• В монорепо — не путай теги между SDK