To revert your project to a previous version on GitHub, find the merged pull request that introduced the problem and click the 'Revert' button — GitHub creates a new PR that undoes all the changes. For individual commits, browse the commit history, find the last good state, and either use the 'Revert' option or manually restore files. Never delete history — always create new commits that undo the unwanted changes.
Reverting Means Undoing Changes Without Losing History
When something goes wrong — a bad deploy, a broken feature, an AI tool that overwrote important code — your first instinct might be to delete the bad changes. But on GitHub, you never delete history. Instead, you create a new change that undoes the old one. This is called reverting. It is like typing the opposite of what was changed: if a line was added, the revert removes it. If a line was deleted, the revert puts it back. The result is that your project returns to its previous state, but the full record of what happened remains intact. GitHub makes this easy with the 'Revert' button on merged pull requests. One click creates a new PR that perfectly reverses all the changes from the original PR. For more granular control, you can browse your project at any commit, find the last good state, and manually restore specific files. This is particularly important when working with AI tools like Lovable or Cursor. Sometimes an AI agent makes sweeping changes that break things, and you need to quickly roll back to a working state. Understanding how to revert gives you a safety net for any experiment.
Prerequisites
- A free GitHub account at github.com
- A repository with a merged pull request or commit you want to undo
- Write access to the repository (collaborator or owner)
Step-by-step guide
Identify the change you want to undo
Identify the change you want to undo
First, figure out which change caused the problem. Go to your repository and click the 'Pull requests' tab. Switch the filter from 'Open' to 'Closed' to see merged PRs. Browse through the list to find the PR that introduced the issue. If you are not sure which PR caused it, click the 'Commits' link on the repository main page and review recent commits — the most recent change is the most likely culprit. Check the dates and commit messages to narrow it down.
Expected result: You have identified the specific pull request or commit that introduced the unwanted change.
Revert a merged pull request with the Revert button
Revert a merged pull request with the Revert button
Open the merged pull request you want to undo. Scroll to the bottom of the PR page where you see the merge confirmation (a purple 'Merged' label). Just below the merge message, look for a 'Revert' button. Click it. GitHub opens a new pull request form pre-filled with the title 'Revert [original PR title]' and a description explaining what is being undone. The new PR contains the exact opposite of every change in the original — additions become deletions and deletions become additions. Click 'Create pull request' to open the revert PR.
Expected result: A new pull request is created that undoes all changes from the original merged PR.
Review and merge the revert PR
Review and merge the revert PR
Before merging the revert, review the 'Files changed' tab to confirm it reverses the right changes. Green lines (additions) in the revert PR should restore content that was deleted in the original PR, and red lines (deletions) should remove content that was added. If everything looks correct, click the green 'Merge pull request' button, then 'Confirm merge.' Your project is now back to the state it was in before the original PR was merged.
Expected result: The revert PR is merged and your project has returned to its previous state.
Revert by restoring files from a previous commit
Revert by restoring files from a previous commit
If the problem was not introduced by a pull request (for example, someone committed directly to main), you can manually restore files. Click 'Commits' on your repository page and find the last commit where everything worked. Click the '<>' icon next to that commit to browse the project at that point in time. Navigate to the file that needs restoring, click the 'Copy raw file' button, then go back to the current version of the file, click the pencil icon to edit, select all text and replace it with the copied content, and choose 'Create a new branch and start a pull request.' This is safe and fully reversible.
Expected result: You have created a PR that restores one or more files to their previous good state.
Verify the project works after reverting
Verify the project works after reverting
After merging the revert, check that your project is working as expected. If your project is deployed (via Lovable Publish, Vercel, or another hosting service), visit the live URL and test the affected pages. If there is a preview deployment on the PR, check that first. Confirm that the issue is resolved and that the revert did not accidentally remove other wanted changes. If needed, RapidDev can help verify that the rollback is complete and no side effects remain.
Expected result: Your project is back to a working state and the problematic changes have been undone.
Complete working example
1# Revert Workflow — Quick Reference23## Method 1: Revert a merged PR (recommended)41. Go to Pull requests tab → Closed52. Find the merged PR that caused the issue63. Scroll to bottom → Click "Revert"74. Review the revert PR → Merge it89## Method 2: Restore files from old commit101. Go to Commits → Find last good commit112. Click "<>" to browse files at that point123. Navigate to the broken file134. Click "Copy raw file"145. Go back to current version → Edit → Paste156. Create new branch + PR → Merge1617## Method 3: GitHub Desktop "Undo" (last commit only)181. Open GitHub Desktop192. Right-click the last commit in History tab203. Select "Revert Changes in Commit"214. Push the revert commit2223## Golden rule:24Never delete commits. Always create NEW commits25that undo the unwanted changes.Common mistakes when reverting to a Previous Version of Your Project in GitHub
Why it's a problem: Trying to delete commits to 'clean up' history
How to avoid: Never delete commits. Create a revert commit that undoes the changes while preserving the full history. Deleting history can break shared repositories.
Why it's a problem: Reverting the wrong pull request
How to avoid: Always review the 'Files changed' tab of the revert PR before merging. Confirm it undoes the changes you want to undo and nothing else.
Why it's a problem: Reverting without checking for dependent changes
How to avoid: If later commits built on top of the change you are reverting, the revert might cause conflicts. Review the revert diff carefully.
Why it's a problem: Committing restored files directly to main instead of using a PR
How to avoid: Always create a pull request when restoring files. This gives you a chance to review and lets teammates see what is being rolled back.
Why it's a problem: Not testing after reverting
How to avoid: Always verify your project works after merging a revert. Check the live site, test key features, and make sure nothing unexpected broke.
Best practices
- Use the Revert button on merged PRs as your first approach — it is the safest and most complete method.
- Always create a pull request for reverts, even if you have permission to commit directly to main.
- Write a clear description in the revert PR explaining why you are reverting and what issue it fixes.
- Test the project after reverting to confirm the fix worked and no side effects were introduced.
- Keep a link to the revert PR in your issue tracker so teammates know what happened and why.
- If an AI tool like Lovable broke something, revert the specific PR before trying another prompt — do not stack fixes on top of broken code.
- Consider creating a project snapshot (tagging a release) before major changes so you always have a known-good version to reference.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
My Lovable app was working fine yesterday but today the pricing page is broken. I found the pull request on GitHub that caused the issue. Walk me through using the Revert button on the GitHub website to undo the changes, step by step.
Frequently asked questions
Does reverting delete the original changes permanently?
No. Reverting creates a new commit that undoes the changes. The original commits remain in the history forever. You can even revert a revert if you change your mind.
Can I revert only part of a pull request?
The Revert button reverses the entire PR. If you only want to undo part of the changes, manually restore the specific files you care about using the file history method described in Step 4.
What if the Revert button creates merge conflicts?
This happens when later changes overlap with the changes you are reverting. GitHub will flag the conflicts in the revert PR and let you resolve them in the browser editor. If the conflicts are complex, ask a developer for help.
Can I revert changes made by an AI tool like Lovable?
Yes. If Lovable is connected to GitHub, every change appears as a commit or PR. You can revert any of them using the same methods described in this guide.
Is there an undo button in GitHub Desktop?
Yes. In GitHub Desktop, go to the History tab, right-click the commit you want to undo, and select 'Revert Changes in Commit.' GitHub Desktop creates a new revert commit locally that you can then push to GitHub.
Can RapidDev help with complex rollbacks?
Yes. RapidDev can help diagnose which changes caused a problem, create targeted reverts that preserve the good changes, and set up branch protection rules to prevent direct commits to main in the future.
Should I revert and then re-apply fixes, or try to fix the broken code directly?
If the breakage is severe, revert first to restore a working state. Then make the fix on a fresh branch and create a new PR. This is safer than trying to patch broken code under pressure.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation