Git Versioning: Safe Commit, Push, Tag & Rollback
Iwan Efendi3 min
A personal note on the worry of losing code and how Git versioning became the answer — from first commit to safe rollback.
I'll be honest — I was worried.
That day, my AI and I had just finished a big round of changes: refactoring the theme hook, adding new utilities, fixing SEO metadata, adding security headers, and deleting some files. Everything felt right. TypeScript was clean, no errors. But one question suddenly surfaced:
Every time we run
The output looks something like this:
Each line is one "photo". The short hash at the front (
Before the photo can be taken, we need to decide what goes into the frame:
A good commit message is an investment. Three months from now,
A commit that only exists on your local machine is vulnerable — if your laptop dies or gets damaged, that history is gone.
Now the project history exists in two places: locally and on GitHub. This is automatic backup.
Hashes like
After this, I don't need to remember the hash. I just need to remember the tag name.
This is the heart of my earlier worry. It turns out there are several ways to "go back", depending on how serious the situation is.
Safe. Nothing in the project changes.
Files are unchanged, but the commit is gone. You're free to edit again and recommit.
After understanding all of this, my workflow became much calmer:
Before starting a big change — create a tag as a checkpoint:
After finishing — commit with a clear message, then push:
If something goes wrong — rollback to the nearest tag:
My earlier worry wasn't unfounded. Losing code you worked hard to write is a real risk — especially when you're still learning and not yet comfortable with Git.
But it turns out Git was designed specifically to eliminate that worry. Every
"If something turns out to be wrong after committing... can we actually go back to the previous version?"That question turned out to be the doorway to a much better understanding of how Git works as a time machine for code.
What Is Versioning in Git?
git commit, Git doesn't just "save files" — it takes a complete snapshot of the entire project at that point in time.
Think of it this way: each commit is a photograph. The collection of those photos forms a travel album of your project's journey.
git log --oneline -5fcb9e5f refactor: audit & hardening — theme hook, utils, security headers
7dbb190 feat: add cross-env dependency and improve code formatting
5c48cab Improve language switcher visibility and styling
374bd29 fix: correct apphosting.yaml secret variable syntax
d04d9bb feat: enhance security & refactor admin role management
fcb9e5f, 7dbb190, etc.) is the unique ID of that snapshot. Whenever I want, I can return to any one of them.
Three Core Actions to Master
git add + git commit — Take the Photo
Before the photo can be taken, we need to decide what goes into the frame:
# Stage all changes
git add -A
# Take the photo with a caption
git commit -m "feat: clear description of what changed""fix: add passive: true to scroll listener in BackToTop" is far more useful than "update".
git push — Send the Photo to the Online Album
A commit that only exists on your local machine is vulnerable — if your laptop dies or gets damaged, that history is gone. git push sends all those snapshots to GitHub:
git push origin maingit tag — Name an Important Milestone
Hashes like fcb9e5f are hard to remember. A tag is a way to give a human-friendly name to an important commit:
# Create a tag at the current commit
git tag v1.1-audit-hardening
# Send the tag to GitHub
git push origin --tagsThree Rollback Scenarios
Scenario 1 — Peek at an Old Version Without Changing Anything
If you just want to see what a file looked like at a certain version without changing anything:# View a specific file from a specific commit
git show 7dbb190:src/components/layout/header.tsxScenario 2 — Undo the Last Commit, Keep the Code
The commit was made but the message was wrong, or you want to edit the code before recommitting:# Undo the commit, but keep file changes intact
git reset --soft HEAD~1Scenario 3 — Safe Rollback to a Specific Version or Tag
This is the correct approach when you genuinely want to return to a previous state, but without deleting history:# Reverse all changes since a specific tag
git revert --no-commit v1.1-audit-hardening..HEAD
git commit -m "revert: back to v1.1 state"
git push origin maingit revert doesn't delete old commits — it adds a new commit that reverses the changes. History stays intact, and this is the best choice for projects already pushed to a shared GitHub repository.
The Workflow I Use Now
git tag v1.2-before-new-feature
git push origin --tagsgit add -A
git commit -m "feat: name of the feature worked on"
git push origin maingit revert --no-commit v1.2-before-new-feature..HEAD
git commit -m "revert: issue found, rolling back to v1.2"
git push origin mainWhat I Took Away From This
commit is a safety net. Every tag is a checkpoint you can use as a lifeline. And git revert is an undo button that doesn't destroy history.
Now I commit more often, write more descriptive commit messages, and every time I'm about to start something big — I create a tag first.
A small habit that makes for a much better night's sleep.Topics
Topics in this note
Explore related ideas through the topics connected to this note.
Share this article
Discussion
Preparing the comments area...