To revert a merge in GitHub, open the merged pull request page and click the "Revert" button near the bottom. GitHub creates a new pull request that undoes all changes from the original merge. Review the revert PR and merge it to restore your project to its previous state. This is the safest way to undo a bad merge without using the command line — especially useful when an AI tool like Lovable or V0 pushed a broken update.
What Does Reverting a Merge Mean?
Sometimes a merge goes wrong. Maybe a pull request from Lovable introduced a bug, V0 pushed a broken component, or a teammate's changes caused unexpected issues in production. Your first instinct might be to panic, but GitHub has a built-in safety net: the Revert button. Reverting a merge doesn't delete history or travel back in time. Instead, it creates a new pull request that contains the exact opposite of the original changes — every line that was added gets removed, and every line that was removed gets added back. When you merge this revert PR, your codebase returns to the state it was in before the problematic merge, and the full history (original merge + revert) is preserved. This is safer than deleting commits because nothing is lost, and everyone on your team can see exactly what happened and why. Reverting is a standard practice even among experienced developers — it's not a sign of failure, it's a sign of good project management.
Prerequisites
- A GitHub account with write access to the repository
- A merged pull request that you want to undo
- A web browser with internet access
- Basic understanding of what pull requests are
Step-by-step guide
Find the merged pull request you want to revert
Find the merged pull request you want to revert
Go to your repository on github.com and click the "Pull requests" tab. By default, you'll see open pull requests. Click the "Closed" filter to see all closed and merged pull requests. Find the specific pull request that caused the issue — you can use the search bar to search by title, author, or PR number. Merged PRs are marked with a purple "Merged" badge. Click on the PR to open its detail page. If the problematic code came from Lovable's GitHub sync, look for PRs authored by the Lovable bot or with commit messages referencing Lovable.
Expected result: You're on the detail page of the merged pull request you want to revert, and you can see the purple "Merged" badge.
Click the Revert button
Click the Revert button
Scroll down on the merged pull request page, past the conversation and commits. Near the bottom, right after the merge confirmation message (which says something like "Pull request successfully merged and closed"), you'll see a "Revert" button. Click it. GitHub will create a new branch and a new pull request that contains the inverse of all changes from the original PR. The new PR's title will be "Revert [original PR title]" and its description will reference the original PR number. If you don't see the Revert button, you may not have write permissions, or the PR may have merge conflicts that prevent an automatic revert.
Expected result: A new pull request is created with the title "Revert [original title]" showing all the inverse changes.
Review the revert pull request
Review the revert pull request
The revert PR opens automatically. Before merging it, take a moment to review what it does. Click "Files changed" to see the diff. Every green line (addition) from the original PR will now be red (deletion), and vice versa. This confirms that the revert will undo exactly the changes from the original merge. Check that no other important code is being removed — if other pull requests were merged after the problematic one, the revert should only affect the original PR's changes. Read through the files carefully, especially if the original PR touched critical files like authentication, payment processing, or database schemas.
Expected result: The Files changed tab shows the inverse of the original PR's changes, and no unintended code is being removed.
Merge the revert pull request
Merge the revert pull request
Once you've confirmed the revert looks correct, scroll down to the merge section. Click the green "Merge pull request" button, then click "Confirm merge." GitHub will merge the revert, applying the inverse changes to your main branch. Your codebase is now back to the state it was in before the problematic merge. If your repository is connected to Vercel or another deployment platform, a new deployment will automatically start with the reverted code. If it's connected to Lovable, the revert will sync back to your Lovable project.
Expected result: The revert PR is merged, your main branch is restored to its pre-merge state, and any auto-deployments begin rebuilding.
Verify the fix and communicate with your team
Verify the fix and communicate with your team
After merging the revert, check your live deployment to confirm the issue is resolved. If you're using Vercel, wait for the deployment to complete (check the Vercel dashboard or the GitHub commit status checks). Visit your live URL and test the functionality that was broken. If everything looks good, leave a comment on both the original PR and the revert PR explaining why the revert was necessary. This creates a clear record for anyone reviewing the project history later. If you need to re-introduce the original changes with fixes, you can create a new branch, apply the fixes, and open a fresh pull request.
Expected result: The live deployment is working correctly, and the project history clearly documents the revert and the reason for it.
Complete working example
1## Revert Summary23This PR reverts #[original PR number].45## Why This Revert Is Needed67- [ ] The original PR introduced a bug in: [describe area]8- [ ] The original PR broke: [describe what stopped working]9- [ ] The original PR caused deployment failure1011## What This Revert Does1213Undoes all changes from the original pull request, restoring14the codebase to its state before the merge.1516## Verification Checklist1718- [ ] Reviewed the diff to confirm only original changes are reverted19- [ ] No other merged PRs are affected by this revert20- [ ] Live deployment tested after merge21- [ ] Team notified about the revert2223## Next Steps2425- [ ] Investigate the root cause of the original issue26- [ ] Create a new PR with the fix applied27- [ ] Re-test before merging the corrected versionCommon mistakes when reverting a Merge in GitHub Using the Revert Button
Why it's a problem: Reverting the revert by accident, re-introducing the bug
How to avoid: After merging a revert PR, GitHub shows a Revert button on it too. Don't click it unless you intentionally want to re-apply the original changes.
Why it's a problem: Not checking if other PRs were merged after the problematic one
How to avoid: If multiple PRs were merged after the one you're reverting, the revert may conflict with those changes. Review the revert diff carefully before merging.
Why it's a problem: Trying to delete the original PR or its commits instead of reverting
How to avoid: Never delete commits from a shared branch. Reverting is the safe approach — it preserves history and can be undone cleanly.
Why it's a problem: Not verifying the live deployment after the revert
How to avoid: Always check your live site after merging the revert. The code change is only half the fix — confirm the deployment succeeded and the bug is actually gone.
Best practices
- Always use the Revert button instead of trying to manually undo changes
- Review the revert diff before merging — verify it only undoes the intended changes
- Leave comments explaining why the revert was necessary for future reference
- Check the live deployment after merging the revert to confirm the issue is resolved
- If the Revert button shows conflicts, get help from a developer rather than forcing it
- After reverting, create a new pull request with the fixed version of the original changes
- Use GitHub's pull request reviews to prevent problematic merges in the first place
- For AI-generated code from Lovable or V0, always test thoroughly before merging to main
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
A pull request from Lovable was merged into my main branch and broke my app. I've already reverted it using GitHub's Revert button. Now I need to fix the original code and re-merge it. Walk me through the steps to create a corrected version of the pull request.
Frequently asked questions
Does reverting a merge delete the original code?
No. Reverting creates a new commit that undoes the changes. The original merge and all its code remain in the repository's history. Nothing is deleted.
Can I revert a revert to re-apply the original changes?
Yes. The revert PR also has a Revert button. Clicking it creates another PR that re-applies the original changes. This is useful when you want to retry after the underlying issue is fixed.
What if the Revert button is not available?
The Revert button may be missing if there are merge conflicts with subsequent changes, or if you don't have write permissions. In this case, you'll need a developer or a service like RapidDev to handle the revert manually.
Will reverting affect my Vercel or Lovable deployment?
Yes. If auto-deploy is enabled, merging the revert PR will trigger a new deployment with the reverted code. This is usually what you want — it deploys the fixed (pre-merge) state of your app.
How do I prevent bad merges in the first place?
Enable branch protection rules (Settings → Branches) to require pull request reviews before merging. This means someone must approve the PR before the Merge button becomes active.
Can I revert only part of a pull request?
No. The Revert button undoes the entire pull request. If you only want to undo specific files or lines, you'll need to create a new pull request that manually removes just those changes.
Is it normal to revert AI-generated code from Lovable or V0?
Absolutely. AI tools sometimes generate code that doesn't work as expected — this is well-documented. Reverting is a professional, standard practice. Always review AI-generated pull requests before merging to reduce the need for reverts.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation