Как работают теги и релизы в Git?

Question

Accepted Answer

**Теги** отмечают важные точки в истории — обычно **релизы** (версии вроде v1.0.0). В отличие от веток, теги — это фиксированные указатели, которые не движутся; они используются для обозначения и ссылки на версии релизов. Они центральны для управления версионированием и релизами.

## Создание тегов

```bash
# annotated tag (recommended for releases — has metadata: tagger, date, message)
git tag -a v1.0.0 -m "Release version 1.0.0"

# lightweight tag (just a pointer, no metadata)
git tag v1.0.0

# tag a specific past commit
git tag -a v1.0.0 <commit> -m "..."
```

**Аннотированные теги** (рекомендуются для релизов) хранят метаданные (автор, дата, сообщение); **лёгкие теги** — это просто имя, указывающее на коммит.

## Работа с тегами

```bash
git tag                        # list tags
git show v1.0.0                # show a tag and its commit
git checkout v1.0.0            # check out the code at a tag (detached HEAD)

# tags are NOT pushed by default — push them explicitly:
git push origin v1.0.0         # push a specific tag
git push origin --tags         # push all tags
```

Важно: **теги не отправляются автоматически** с `git push` — вы отправляете их явно.

## Теги и ветки

```text
BRANCH → a MOVABLE pointer that advances as you commit (ongoing development)
TAG    → a FIXED pointer to a specific commit (a permanent label — doesn't move)
→ Use tags to permanently mark releases/milestones; branches for ongoing work.
```

## Семантическое версионирование и релизы

```text
SEMANTIC VERSIONING (SemVer): MAJOR.MINOR.PATCH (e.g. v2.3.1)
  MAJOR → breaking changes | MINOR → new features (compatible) | PATCH → bug fixes
→ Tags label these versions. Platforms (GitHub) build "Releases" from tags
  (with release notes, built artifacts) for distribution.
```

## Почему это важно

Понимание тегов и релизов ценно для **управления версионированием и релизами**, поэтому это полезное практическое знание для работы с выпущенным программным обеспечением. **Теги** отмечают важные точки в истории — обычно **версии релизов** (вроде v1.0.0) — предоставляя фиксированные, постоянные ссылки на конкретные коммиты, что необходимо для отслеживания и определения того, какой код составляет каждый релиз.

Понимание различия между **аннотированными тегами** (рекомендуются для релизов, сохраняют метаданные вроде автора, даты и сообщения) и лёгкими тегами — это практическое знание для правильного тегирования релизов.

Знание того, как создавать, перечислять и переходить к тегам, и важно, что **теги не отправляются автоматически** (требуется явный `git push origin --tags` или отправка конкретных тегов — распространённая ошибка, когда люди создают теги, но забывают их отправить), необходимо для правильного управления тегами релизов.

Понимание **теги и ветки** (тег — это фиксированный указатель на конкретный коммит — постоянный ярлык, который не движется — в то время как ветка — это движущийся указатель, который продвигается вместе с разработкой) уточняет их разные роли: теги для постоянного отмечания релизов/вех, ветки для текущей работы.

Понимание связи с **семантическим версионированием** (соглашения MAJOR.MINOR.PATCH для обозначения природы изменений) и то, как платформы создают **Релизы** из тегов (с примечаниями релиза и артефактами для распределения), отражает то, как теги вписываются в реальное управление релизами.

Поскольку выпуск и версионирование программного обеспечения — это общая необходимость, а теги — это механизм Git для отмечания и ссылки на версии релизов (центральный для управления релизами и интегрированный с функциями релизов платформ), понимание тегов и релизов — аннотированных и лёгких тегов, отправки их, тегов и веток, и их роли в версионировании/релизах — это ценное, практически релевантное знание Git для управления выпущенным программным обеспечением, полезный аспект профессиональной разработки, связанный с соглашениями о версионировании и процессами релизов.