Recover through Git

You shipped a bug. The cleanest way back, when the bug is in your code, is a Git revert. git revert creates a new commit that undoes the bad one, and Vercel builds that commit like any other push.

Here is the whole flow:

git log --oneline -3
# 8c1d2e4 Add year to footer
# 4f2a9c1 Show note count on home page
# b7e0f33 Fix health route

git revert 8c1d2e4
git push origin main

Vercel picks up the push, builds a new Production deployment, and moves the domain to it when the build succeeds. Then you run the smoke test, same as after any release.

Why a revert and not a force-push

A revert keeps the history honest. Anyone reading git log next month sees the bad commit, the revert, and the reason in the commit message. A force-push erases the evidence and breaks every clone that already pulled the bad commit.

It also keeps Git and Production in agreement. After a revert, the code on main is the code serving traffic. That’s not true after a platform rollback, which we cover later. Rollback is faster when seconds matter. But always follow it with a source fix, or the next push brings the bug straight back.

A revert is a new build, not an old one

Reverting changes source, so Vercel builds a fresh deployment with today’s project settings and today’s environment variables. That is often good: you get the current secrets and the current Node.js version. But the result is not byte-for-byte the release you had before. Check the new deployment id and repeat the production checks.

What a revert can’t undo

Reverting code doesn’t reverse a database migration, unsend an email, restore a deleted file, or take back an API call.

Before you revert, ask three questions. Are those side effects compatible with the old code? Do they need a compensating action, like a migration that adds the column back? Or do they make the old code unsafe to run at all? Sometimes the honest answer is to fix forward instead.

Try this on your own project: on a practice branch, push a harmless visible regression, like a footer that says “2025” again. Let the Preview build, revert the commit, push, and confirm the new preview shows the correct footer.