A release is a commit, and a commit hash is hard to find. A tag names it, and the tag is what a build, a bug report, and a bisect all point at. Untagged releases are a history you cannot navigate.
About 1 min of reading
Tag a release.
The tag
Before you run it, say out loud what it will print. Then open the answer.
The list
Before you run it, say out loud what it will print. Then open the answer.
Tags do not travel with a branch by default. A release tag that never reached the remote is a release no one else can build from, which is the failure mode of a local only workflow.
A command that lists the tags with their dates is the release history. That list is what a team reads when asked 'what shipped in March', and it only works if the tags exist.
An annotated tag is an object with a date, an author, and a message. A lightweight tag is a pointer. For a release, the object is what you want, because the message is where the 'what shipped' note lives.
Tag the commit that is the artifact. Tagging a merge that happened later tags something that was not shipped, and the difference matters when you rebuild from the tag.
v2.4.1 or release-2.4.1, chosen once and used always. Two conventions in one repository is a search that misses half the releases.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.