Images are reused AI-generated editorial illustrations, not documentary photographs or verified product screenshots.
What is a Git tag? It is a named reference commonly used to mark a release or other important point in repository history. Unlike a working branch, a release tag is normally kept fixed. That stability helps clients identify exactly which source version was delivered, although a tag alone does not prove which code was deployed.
Choose lightweight or annotated deliberately
A lightweight tag points directly to an object. An annotated tag stores additional information such as a message and tagger details, and can be signed. Git’s documentation recommends annotated tags for releases. Follow the client’s naming policy and do not imply that an unsigned label authenticates the author.
Tag the reviewed commit, not a guess
Check the intended commit and confirm that release tests passed. An example is git tag -a v1.2.0 -m "Release v1.2.0" <commit> in a repository you control. Use the actual reviewed identifier. A version name is a convention; Git does not inspect whether the application deserves a particular version number.
Publish the specific tag and keep it stable
Creating a tag is local until it is pushed. When authorized, git push origin v1.2.0 shares that specific tag. Avoid moving a published release tag to conceal a fix. Create a new release label and document the change so downstream users can distinguish the old and corrected artifacts.
A practical checklist
- Confirm the release commit and test evidence.
- Follow a consistent version naming policy.
- Choose an annotated tag for the release record.
- Push the intended tag explicitly.
- Keep deployment and release notes tied to the identifier.
Worked example
Illustrative example: a freelancer delivers a website integration tagged v1.2.0. A later bug fix becomes v1.2.1 instead of silently moving v1.2.0. The handover records the deployed commit separately, allowing the client to compare the release label with what the hosting system actually runs.
Common questions
Is a tag a backup? No; repository and artifact backups remain separate responsibilities. Does a tag automatically create a hosted release page? Not necessarily. Are signed tags always trusted? Verification still depends on trusted keys and a suitable signing policy.
What to do next
Include the release tag, commit identifier and deployment evidence in your handover. Keep old release labels understandable instead of recycling them for new code.
Sources and further reading
Related reading
- A Practical Git Workflow for Freelance Client Projects
- Writing a Freelance Handover Document Clients Can Use
Git Describe: Turn Release History into a Useful Version Label