If a bad commit broke your project, do not panic — GitHub keeps every previous version. Browse the commit history to find the last working state, view the files at that point, and restore them by copying the content and creating a new pull request. In GitHub Desktop, right-click a bad commit and select 'Revert Changes in Commit' to undo it instantly. The key rule: never delete history, always create a new commit that fixes the problem.
A Bad Commit Is Not a Disaster — Everything Is Recoverable
One of the biggest fears for non-technical founders is accidentally breaking their project. Maybe you or an AI tool like Lovable committed something that broke the homepage. Maybe a Cursor Agent went rogue and changed too many files at once. Maybe you approved a PR that should not have been merged. Here is the good news: on GitHub, nothing is ever truly lost. Every commit is a snapshot of your entire project. Even after a bad commit, all the previous good versions still exist in the history. You just need to find the right one and restore it. There are several ways to recover. The easiest is using GitHub Desktop's 'Revert Changes in Commit' feature, which creates a new commit that perfectly undoes the bad one. If you prefer the web, you can browse the history, find the last good commit, view the files at that point, copy their content, and create a pull request to restore them. The approach depends on whether you need to undo one commit, restore one file, or roll back the entire project. This guide covers all three scenarios.
Prerequisites
- A free GitHub account at github.com
- A repository with at least one commit you want to recover from
- GitHub Desktop installed (optional, for the Desktop undo method)
Step-by-step guide
Identify the bad commit in your history
Identify the bad commit in your history
Go to your repository on GitHub and click the 'Commits' link near the top of the file list. Scan the list of commits, reading the messages and dates. Look for the commit that introduced the problem. If you are not sure which one it is, click on recent commits to view their diffs — the file changes will help you identify which commit broke things. Pay attention to the timestamps: if your app worked at 2pm but broke at 3pm, look at commits between those times.
Expected result: You have identified the specific commit (or commits) that caused the problem.
Find the last good commit before the problem
Find the last good commit before the problem
In the commits list, look at the commit just before the bad one — this is your last known good state. Note its commit hash (the short alphanumeric code on the right side, like 'e4f5g6h'). Click the '<>' icon next to that commit to browse the repository as it was at that point. Verify this is a good state by navigating to the files that are currently broken and confirming they look correct.
Expected result: You are browsing the repository at the last good commit and can see that the files look correct.
Restore a single file from the good commit
Restore a single file from the good commit
If only one or two files need restoring, navigate to the file while browsing the good commit. Click the 'Copy raw file' button (clipboard icon) to copy the entire file content. Then navigate back to the current version of the repository (click the branch dropdown and select 'main'). Go to the same file, click the pencil icon to edit, select all the content (Ctrl+A or Cmd+A), paste the old version (Ctrl+V or Cmd+V), and choose 'Create a new branch for this commit and start a pull request.' Write a message like 'Restore Pricing.tsx to pre-bug version.' Create and merge the PR.
Expected result: The file has been restored to its previous good version via a pull request.
Use GitHub Desktop to undo the last commit
Use GitHub Desktop to undo the last commit
If you have GitHub Desktop installed, open it and select your repository. Click the 'History' tab on the left to see the commit list. Find the bad commit, right-click on it, and select 'Revert Changes in Commit.' GitHub Desktop creates a new commit that perfectly reverses all the changes from the bad commit. Click 'Push origin' in the top bar to send this revert to GitHub. This method is fast, safe, and works for any commit — not just the most recent one.
Expected result: The bad commit is undone by a new revert commit, and the changes are pushed to GitHub.
Verify the recovery worked
Verify the recovery worked
After restoring files or reverting the commit, check that your project works. If your project is deployed, visit the live URL and test the affected pages. On GitHub, navigate to the files you restored and verify they show the correct content. If you used the PR method, check the merged PR to confirm the right changes were applied. If the project was built with an AI tool like Lovable, you may need to trigger a new publish after the recovery. If you need help verifying complex recoveries, RapidDev can audit the restored state to ensure nothing was missed.
Expected result: Your project is working again and the bad commit's changes have been successfully undone.
Complete working example
1# Bad Commit Recovery Checklist23## 1. Identify the problem4- [ ] When did the problem start? (date/time)5- [ ] What is broken? (which page, feature, or error)6- [ ] Which commits happened around that time?78## 2. Find the last good state9- [ ] Click Commits → scan the list10- [ ] Click the commit BEFORE the bad one11- [ ] Browse files at that commit → verify it works1213## 3. Choose your recovery method1415### Option A: GitHub Desktop Revert (fastest)16- [ ] Open GitHub Desktop → History tab17- [ ] Right-click bad commit → Revert Changes18- [ ] Push to GitHub1920### Option B: Web file restore (no install needed)21- [ ] Browse good commit → Copy file content22- [ ] Edit current file → Paste old content23- [ ] Create PR → Review → Merge2425### Option C: Revert merged PR26- [ ] Find the merged PR → Click Revert button27- [ ] Review revert PR → Merge2829## 4. Verify30- [ ] Check live site or preview31- [ ] Test affected features32- [ ] Confirm no side effectsCommon mistakes when recovering Changes After a Bad Commit in GitHub
Why it's a problem: Panicking and making more changes on top of broken code
How to avoid: Stop and revert first. Get back to a working state before trying to fix or add anything new.
Why it's a problem: Trying to force-push or delete commits to erase the mistake
How to avoid: Never delete history. Force-pushing can break shared repositories. Always create a new commit that undoes the bad change.
Why it's a problem: Restoring to the wrong commit
How to avoid: Before restoring, browse the project at the target commit and verify the broken pages look correct. Double-check dates and messages.
Why it's a problem: Forgetting to push the revert from GitHub Desktop
How to avoid: After creating a revert commit in GitHub Desktop, you must click 'Push origin' to send it to GitHub. Local reverts do not affect the live project.
Best practices
- Stay calm — nothing is lost on GitHub. Every previous version is always accessible.
- Revert first, investigate later. Get your project working, then figure out what went wrong.
- Use GitHub Desktop's Revert feature for the quickest recovery — no copy-pasting needed.
- Always restore via a pull request when using the web, so the recovery can be reviewed.
- After recovering, note what caused the problem so you can avoid it in future prompts or changes.
- If using AI tools, duplicate your project before making major changes — both Lovable and Replit support project duplication.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
My Lovable app homepage was working yesterday but shows a blank page today. I think a recent commit broke it. Walk me through finding the bad commit on GitHub, reverting to the last working version, and verifying the fix — all using the GitHub website, no terminal commands.
Frequently asked questions
Is it possible to permanently lose work on GitHub?
Extremely unlikely. Every commit is stored permanently in the repository's history. Even if a file is deleted, its previous versions still exist in older commits. The only way to truly lose work is if the entire repository is deleted and not backed up.
Can I undo a revert if I change my mind?
Yes. Since a revert is just another commit, you can revert the revert — creating a new commit that re-applies the original changes. On a merged revert PR, click the Revert button again.
What if the bad commit was made by an AI tool and I do not understand the changes?
You do not need to understand the changes to revert them. The GitHub Desktop Revert feature or the web PR Revert button undo everything automatically. Just find the bad commit and revert it.
How do I prevent bad commits in the future?
Use pull requests for all changes instead of committing directly to main. Enable branch protection rules so every change must be reviewed before merging. If using AI tools, review the diff before approving.
Should I use GitHub Desktop or the web to recover?
GitHub Desktop is faster for simple reverts — right-click and done. The web method is better when you need to restore specific files or when you do not have Desktop installed.
Can RapidDev help recover from a broken AI-generated commit?
Yes. RapidDev can diagnose which AI-generated changes broke your project, perform targeted reverts that preserve the good changes, and set up safeguards to prevent similar issues in the future.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation