The Release scenario

Your milestone is complete and you got the greelight to release. Congrats! You're almost there.

If the last commit on main is just the right spot, and it has everything you need for the release and nothing more, just checkout main and tag:

git checkout main

# Make sure you're up to date. Just in case.
git pull

# Then tag. And push it.
git tag -a 1.1.0
git push origin 1.1.0

The "annotated" tag

This -a argument means "annotation", you'll be redirected to a code editor for the tag. It's a bunch of text you can attach to the tag to explain what your tag is for, what it contains. Please refrain from using the actual tag name (1.1.0) to express a goal, an event or anything: this name is going to be used by some SemVer tool at some point, so it's better be a strict SemVer string, not "DemoSeptember2025".

---

Some devs already merged something on main before I could tag, and we cannot release these features!

Let's say you've got 4 features, GG-1 to 4, but you only want to release GG-1 and GG-2.

Nothing prevents you from tagging something "in the past", as in, a few commits earlier: just check the git logs, pinpoint on main when the release should have happened (i.e. : the last commit you want to release), copy its id and use it to tag

git checkout main

# Make sure you're up to date. Just in case.
git pull

# Check the logs. Get the correct commit ID
git logs

commit 4eb62897ec9adcc2d5c66a9be39d5540483c4d16
Author: Mickaël Forgh <git@gud.com>
Date:   Mon Oct 20 01:01:31 2025 +0200

    feat(GG-2): Added walls

# Then tag it. And push it.
git tag -a 1.1.0 4eb62897ec9adcc2d5c66a9be39d5540483c4d16
git push origin 1.1.0

There you are. You've got your 1.1.0 release, without onboarding feat(GG-3) and feat(GG-4).

And that's it! Tagging a specific commit on main is all you need to do. Your CI/CD tools can then check out this tag just like a branch to build and deploy it.

git checkout 1.1.0