How to Recover a Broken App Using GitHub

When an app breaks after a code change, GitHub can help you find what changed and recover a working version. The safest approach is to identify a known-good commit, create a recovery branch, undo the faulty change, and review the result before it reaches your default branch. These steps work whether you use Git on your computer or GitHub's web interface for inspection.

Check whether the problem is in the app or the deployment

Note when the issue began, what behavior changed, and whether a recent GitHub commit or deployment lines up with it. GitHub stores source history, but production may be running a different commit. Check your hosting dashboard for the deployed commit or release before assuming the newest GitHub code is what users see.

If production is down and the host offers a deployment rollback, restoring a known-good deployment may be the fastest temporary recovery. Then repair the source branch separately so the next deployment does not reintroduce the problem.

Find the change in GitHub history

Open the repository on GitHub and select the branch that your app deploys from. Browse its commit history and inspect the commits made just before the issue appeared. A commit's changed files and diff help you connect a change to the failing behavior.

For a local checkout, fetch the latest remote history and inspect the recent commits:

git fetch origin
git log --oneline --decorate origin/main -10

Replace main with the branch your project actually uses. Before changing files, check git status and save or commit any unrelated local work.

Create a recovery branch and revert the faulty commit

Start from the latest version of the affected branch and create a separate branch for the fix:

git switch main
git pull --ff-only origin main
git switch -c fix/restore-working-app

Replace main if your default branch has a different name. If the faulty change is a commit on this branch, reverse it with its commit ID:

git revert <commit-id>

A revert creates a new commit rather than deleting published history. If Git reports conflicts, resolve them carefully and inspect the result; if the bad behavior spans multiple commits, determine the right range before reverting. Avoid force-pushing or resetting a shared branch to make a rollback.

Test, push, and review the recovery

Run the checks that previously failed and confirm the affected feature works. Then inspect and push the recovery branch:

git status
git show --stat --oneline HEAD
git push -u origin fix/restore-working-app

Open a pull request on GitHub, describe the incident and the recovery, and let required checks and reviewers run before merging. Verify your deployment workflow then publishes the intended commit. For a deeper comparison of restore, reset, and revert, read how to undo a Git commit safely.

If the app is still broken

A source rollback cannot fix every production problem. Check build logs, runtime errors, environment configuration, and database compatibility. If a rollback changes application code but leaves a newer database schema in place, the older code may still fail. Confirm the actual deployed commit and investigate the first failing error rather than repeatedly reverting unrelated changes.