Git tags and releases: how to know which version is in production
Published on 2026-10-26 by frfrand
Version deployments and recover the exact commit of an app

If they ask you «what version is in production?» and you answer «the latest from main», you have a traceability problem. A branch can keep advancing. A tag identifies a specific revision and makes it easier to find again.
The idea is to use it to solve a real problem, not memorize commands because they look good in a screenshot. Let's go with the essentials, a work example, and the errors it's best to avoid.
What Git tags and releases do and when they are useful
Lightweight tags work as references; annotated ones store metadata such as message and creator. A release on GitHub usually organizes notes and artifacts around a tag. None of those things deploys the application by itself.
If you are learning, try it first in a repository or test environment. If you manage production, document the state before executing anything that alters files, history, or data. That allows you to understand what changed and recover if you make a mistake.
Example to copy and understand
git status
git log -1 --oneline
git tag -a v1.4.0 -m 'Lanzamiento 1.4.0'
git push origin v1.4.0
git show v1.4.0
git rev-parse v1.4.0^{}
Do not copy the final command without checking the previous state. Branch names, host, user, or paths are examples; replace them with those from your project. Some commands modify files or make requests that can write data.
How I would use it step by step
- Step 1. Choose a stable versioning convention, for example
v1.4.0. - Step 2. Tag the commit that was actually tested, not one that hasn't run in staging yet.
- Step 3. Publish the tag and document important changes and migrations.
- Step 4. Save the tag and the hash in the deployment record.
- Step 5. To revert, check data compatibility and return to a known version using a tested procedure.
Stop after each step and check the result. If something fails, note the exact message before changing strategy. Jumping between five random solutions usually makes it harder to find the real cause.
A case that could happen to you working with clients
The tours platform incorporates coupons. Version v1.4.0 changes the API and a migration; the tag allows knowing exactly what code was published and what changes there were since v1.3.0.
The goal is not for it to "work once", but for you to be able to explain how you repeat it without compromising another application. If there is customer data or credentials, work with separate tests and minimal accesses.
The mistake I see most
Do not reuse the same tag to point to different commits: it confuses artifacts, caches, and auditing. And remember that reverting to the previous tag does not necessarily undo migrations.
A simple rule: if you cannot explain what the command will do to your code or server, check its official help first. This way you avoid confusing a quick fix with a new problem.
Where does ArduMaker come in?
At ArduMaker you can deploy from Git repositories. Link each publication to the tag or hash to investigate server errors and coordinate backend changes with persistent data.
For example, you can deploy from a Git repository to a VPS, associate an HTTPS domain, and manage services and databases from the same environment. The panel reduces repetitive infrastructure tasks, but does not replace Git, testing, or project permission review.
Quick questions before applying it
Does this change production? It depends on where you run the action. Test locally first, identify the affected commit or service, and prepare a recovery plan.
How do I check that it went well? Don't settle for the absence of error messages: check the status, run a functional test, and verify the corresponding logs or history.
Is it worth automating it? If it is repeatable and has verifiable results, yes. But automation should fail clearly and not hide errors or credentials.
To learn more
Summary: the useful tool is not the one with the most options, but the one that allows you to understand what changed, verify it, and keep working without surprises.