Як теги використовуються для релізів?

Теги використовуються для релізів як фіксована точка в історії Git, яка однозначно визначає версію продукту і слугує тригером для релізу і CI/CD.

Простіше кажучи: реліз = конкретний коміт + тег версії.

---

#Основна ідея

• код вважається готовим
• на потрібний коміт ставиться тег версії
• усе, що стосується релізу, прив'язується до цього тегу

Тег стає «якорем» релізу.

---

#Типовий процес релізу з тегами

1. Код в основній гілці готовий (main, release/*)
2. Створюється annotated tag:

3. Тег пушиться у віддалений репозиторій:

4. CI/CD реагує на тег:

• збирає проект
• запускає тести
• деплоїть у потрібне середовище

5. На GitHub / GitLab створюється реліз:

• опис змін
• прикріплені артефакти

---

#Чому для релізів використовують саме теги

#Фіксована версія

• тег не рухається
• версія v1.3.0 завжди = той самий код

---

#Відтворюваність

• можна перезібрати реліз через роки
• легко знайти код конкретної версії

---

#Інтеграція з CI/CD

• пайплайни часто налаштовані так:

  «деплой у прод - тільки за тегом»

---

#Зрозуміла історія релізів

• список тегів = історія версій
• зручно орієнтуватися в розвитку продукту

---

#Lightweight чи annotated?

Для релізів майже завжди:

annotated tag

Тому що:

• є опис
• є автор і дата
• можна підписати тег
• зручно для аудиту

---

#Часте питання на співбесіді

Чому не робити реліз із гілки?

Тому що:

• гілка змінюється
• сьогодні main - одне, завтра - інше
• неможливо гарантувати точну версію

Тег вирішує цю проблему.

---

#Коротка відповідь для співбесіди

Теги використовуються для релізів як незмінні мітки версії: на потрібний коміт ставиться тег, за яким запускається CI/CD, створюється реліз і фіксується конкретний стан коду.