How to Restore a Previous Version of Your App

If a recent code change or deployment caused a problem, you may need to restore a previous version of your app. The right method depends on what you need to recover: a live production deployment, a Git commit, or just one file. This guide explains the difference and shows how to roll back without accidentally losing newer work.

Practice Git workflows →

First, decide what “restore” means

Live app is broken:use your hosting provider's deployment history to redeploy a known-good build, if available.
Your local code is wrong: use Git to restore a file or create a commit that reverses a bad change.
You need an older version to develop from: inspect the commit history and check out that commit on a separate branch.

A deployment rollback changes what users receive, but it does not necessarily change your Git branch. A Git rollback changes the repository, but it does not guarantee that production has been redeployed. Treat these as related but separate actions.

Restore the live deployment

Open your hosting provider's project dashboard and find the deployment history. Select a successful deployment from before the issue and use the provider's redeploy or rollback option. The exact labels and behavior differ by platform; verify the target project, branch, environment, and commit before confirming.

After the rollback, test the live URL and monitor logs. Check whether the deployment includes database migrations, background jobs, or other external changes: restoring older application code does not automatically reverse those changes. If you cannot identify a safe deployment, contact the project's maintainer or hosting support rather than guessing.

Find the previous version in Git

In the project folder, review recent commits and identify a known good point in the history:

git status
git log --oneline --decorate -10

If you want to inspect or run the old version without moving your current branch, create a separate branch at the commit:

git switch -c inspect-old-version <commit-id>

Replace <commit-id> with the hash shown by git log. This makes a new branch at that historical commit; it does not update your production app or erase the branch you left.

Undo a bad change while keeping later history

If the bad change is already committed and you want to undo it on your current branch, use git revert. It adds a new commit that reverses the selected commit, which is generally safer than rewriting history that may already be shared:

git log --oneline
git revert <commit-id>

Resolve any conflicts Git reports, run the tests, and review the resulting commit. If you only need one earlier file, compare its history first and restore that path rather than reverting an entire commit. See how to undo a Git commit for options based on whether the commit has been shared.

Verify the rollback and prevent repeat incidents

Check the repository with git status, run the project tests or build, and confirm the app behaves as expected. For a live deployment, check the deployed commit and test the production URL. Make a follow-up fix on a branch and redeploy it after review; do not rely on an emergency rollback as the permanent fix.