How are tags used for releases?

Tags are used for releases as a fixed point in the Git history that unambiguously identifies a product version and serves as a trigger for the release and CI/CD.

Simply put: a release = a specific commit + a version tag.

---

#The basic idea

• the code is considered ready
• a version tag is placed on the right commit
• everything related to the release is tied to that tag

The tag becomes the "anchor" of the release.

---

#A typical release process with tags

1. The code in the main branch is ready (main, release/*)
2. An annotated tag is created:

3. The tag is pushed to the remote repository:

4. CI/CD reacts to the tag:

• builds the project
• runs the tests
• deploys to the target environment

5. A release is created on GitHub / GitLab:

• a description of the changes
• attached artifacts

---

#Why tags specifically are used for releases

#A fixed version

• the tag does not move
• version v1.3.0 always equals the same code

---

#Reproducibility

• the release can be rebuilt years later
• it is easy to find the code of a specific version

---

#Integration with CI/CD

• pipelines are often configured so that:

  "deploy to production only by tag"

---

#A clear history of releases

• the list of tags is the history of versions
• convenient for tracking the product's evolution

---

#Lightweight or annotated?

For releases, it is almost always:

an annotated tag

Because:

• it has a description
• it has an author and a date
• the tag can be signed
• it is convenient for auditing

---

#A frequent interview question

Why not make a release from a branch?

Because:

• a branch changes
• today main is one thing, tomorrow it is another
• it is impossible to guarantee an exact version

A tag solves this problem.

---

#Short answer for an interview

Tags are used for releases as immutable version markers: a tag is placed on the right commit, CI/CD is triggered by it, a release is created, and a specific state of the code is fixed.