Git revert, reset and restore: what to use to undo changes without losing work
Published on 2026-10-26 by frfrand
Choosing between reverting a commit, moving HEAD, or recovering a file
Three commands to “undo” that do not do the same thing. Choosing wrong can erase local changes or rewrite a branch that other people are already using. It’s worth knowing the difference before copying a command with --hard.
The idea is to use it to solve a real problem, not to memorize commands because they look good in a screenshot. Let’s go with the essentials, a work example, and the mistakes most worth avoiding.
What Git revert, reset, and restore do and when they’re useful
git revert creates a commit that undoes the effect of another: it’s appropriate for changes already shared. git reset moves the branch reference and can alter the index and files; --hard discards uncommitted work. git restore recovers files from the index or a revision according to options.
If you’re learning, try it first in a test repository or environment. If you manage production, document the state before running anything that alters files, history, or data. That lets you understand what changed and recover if you make a mistake.
Example to copy and understand
# Deshacer un commit publicado sin reescribir historial
git revert abc1234
# Ver el estado antes de tocar archivos
git status
git diff
# Recuperar UN archivo modificado localmente
git restore -- ruta/al/archivo.py
# Mover HEAD conservando cambios en staging
git reset --soft HEAD~1Don’t copy the final command without checking the prior state. Branch names, host, user, or paths are examples; replace them with your project’s. Some commands modify files or make requests that can write data.
How I’d use it step by step
- Step 1. If the commit is already on a shared branch, prefer
revertand check for possible conflicts. - Step 2. For a local file you want to discard, inspect
git difffirst. - Step 3. To correct a commit not yet published, evaluate
reset --softor--mixeddepending on whether you want to keep staging. - Step 4. Avoid
reset --hardunless you are absolutely sure those changes can be lost. - Step 5. Before deploying the rollback, run the tests and verify database migrations.
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
An incorrect price change is published on a website. On shared main, it is better to create a traceable revert, not push a forced reset that moves everyone's history.
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 client data or credentials, work with separate tests and minimal access.
The mistake I see most often
Reverting code does not revert a PostgreSQL migration nor a data operation. If the deployment modified the schema, you need a specific plan for compatibility and recovery.
A simple rule: if you can't 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?
With ArduMaker's Git deployment, keeping the hash of each version allows associating an error with a commit. But reverting base files and persistent files must be designed separately.
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 reviewing project permissions.
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's repeatable and has verifiable results, yes. But automation should fail clearly and not hide errors or credentials.
To expand
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.