git-release-tag

name	git-release-tag
description	Создаёт semver-тег для релиза с генерацией changelog из коммитов с прошлого тега. Определяет нужный bump (patch/minor/major) по содержимому коммитов, формирует release notes. Используй, когда пользователь хочет «выпустить релиз», «бампнуть версию», «поставить тег», «сделать релиз», «затегать».

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

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

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

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

• монорепо с несколькими SDK или одиночный пакет?
  • монорепо → теги вида <sdk>/v<X>.<Y>.<Z> (например, sdk-go/v0.3.1)
  • одиночный → v<X>.<Y>.<Z>
• если монорепо — спроси пользователя, какой SDK тегаем

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

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
feat!: или BREAKING CHANGE: в теле	major
feat: без breaking	minor
только fix:, perf:, refactor:, docs:, chore:	patch
ничего значимого (только chore без изменений в коде)	спросить пользователя

Если коммиты не по конвенции — покажи их пользователю и спроси, какой 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