Git deployment workflow
Recover through Git
Revert a bad source change, let the platform build a new known-good release, and preserve an auditable repository history.
8 minute lesson
When the fault is in source code, a Git revert is often the clearest recovery. It creates a new commit that undoes the bad change.
Reverting preserves evidence and keeps the repository aligned with production. Push the revert to the production branch, monitor its build, and smoke-test the result. Platform rollback is faster when seconds matter and is covered later, but follow it with a source correction so the next deploy cannot reintroduce the same bug.
A Git revert changes source, so it creates a fresh deployment using current project settings and environment variables. That can be an advantage over restoring an old artifact, but it also means the result is not byte-for-byte identical to the previous release. Verify the new deployment ID and repeat the production checks.
Source recovery does not reverse database migrations, sent messages, deleted objects, or external API calls. Before reverting, decide whether those effects are backward compatible, need compensation, or make the old code unsafe. Avoid force-pushing the production branch: an explicit revert gives reviewers and operators an auditable explanation of the recovery.
Introduce a harmless visible regression on a practice branch, deploy it to Preview, revert the commit, and confirm the new preview restores the prior behavior.
Lesson completed