Объясните, что делают эти Git-команды и почему теги часто используют для обозначения релизов

Короткий ответ

`git tag -a v1.2.0 -m "..."` создаёт аннотированный тег, который навсегда фиксирует конкретный коммит под именем версии; `git push --tags` отправляет этот тег в удалённый репозиторий; теги используют для релизов, потому что они дают неизменяемую, легко читаемую ссылку на точную версию кода, из которой был собран релиз.

Как это работает подробнее

в отличие от веток, которые постоянно двигаются вперёд с новыми коммитами, тег — это фиксированная метка на одном коммите (аннотированный тег к тому же хранит автора, дату и сообщение, как отдельный Git-объект). Многие CI-системы умеют запускать отдельный пайплайн релиза именно по событию создания тега.

Пример кода

example.shКопировать

git tag -a v1.2.0 -m "Release 1.2.0: добавлена поддержка экспорта в CSV"
git push origin v1.2.0

Что использовать на практике

• На практике. соглашение называть теги по semver (`v1.2.0`) позволяет автоматически генерировать changelog, прикреплять артефакты к GitHub/GitLab Release и однозначно идентифицировать, какая версия кода работает в production. Тег также удобен для обратной трассировки инцидента — заводская ревизия легко сопоставляется с кодом на момент релиза.
• Пример. Ожидаемое поведение: в удалённом репозитории появляется тег `v1.2.0`, по которому можно собрать релизный артефакт командой наподобие `git checkout v1.2.0`, и пайплайн, настроенный на триггер `tags: - 'v*'`, автоматически запускает релизную сборку.

Подводные камни

• Частые ошибки. переиспользуют и перезаписывают один и тот же тег для разных коммитов (`git tag -f`), что ломает воспроизводимость и доверие к версии; путают лёгкие (lightweight) и аннотированные теги, хотя для релизов рекомендуются именно аннотированные — с метаданными.