GitHub Revert the Revert: Reapply a Rolled Back PR Safely (2026 Guide)
If you rolled back a PR and now need the same change set back, the safest path is often revert the rollback commit ("revert-the-revert").
This preserves history and avoids risky force-push recovery on shared branches.
Table of contents
1. Quick decision table
| Situation | Use this | Why |
|---|---|---|
| You need the exact reverted PR back | git revert <rollback-commit-hash> |
Reapplies the same change set as a new commit. |
| You need only part of old changes | Open a new PR / cherry-pick specific commits | Prevents accidental over-restore. |
| Rollback commit was a merge revert | Revert the rollback commit itself | Usually simpler than rebuilding PR manually. |
| Protected branch with required checks | Recovery branch + PR | Keeps policy, audit, and approvals intact. |
| Reapply collides with newer commits | Resolve conflicts and continue | History stays linear and reviewable. |
2. Find the rollback commit to revert
Before running commands, locate the rollback commit hash precisely.
git switch main
git pull --ff-only
git log --oneline --decorate -n 30
# find the rollback commit message, usually starts with "Revert \"...\""You can also inspect files changed by that rollback:
git show --name-only <rollback-commit-hash>3. GitHub UI workflow
- Open the rollback commit or rollback PR in GitHub.
- If GitHub shows Revert, click it to open a reapply PR.
- Review diff scope carefully (especially config, migrations, feature flags).
- Run required checks and merge after approval.
If GitHub does not show the button or predicts conflicts, use the CLI workflow below.
4. CLI workflow for reliable reapply
A) Reapply from rollback commit hash
git fetch origin
git switch -c reapply/pr-123 origin/main
git revert <rollback-commit-hash>
git push -u origin reapply/pr-123B) Reapply when rollback involved multiple commits
git fetch origin
git switch -c reapply/pr-123 origin/main
git revert --no-commit <rollback1> <rollback2>
git status
git diff --staged
git commit -m "Reapply PR #123 after rollback"
git push -u origin reapply/pr-123C) Validate before merge
git show --name-only HEAD
git log --oneline --decorate -n 8Then open a PR and label it clearly as a reapply/recovery change.
5. Protected branch flow
For protected branches, keep the reapply path policy-compliant:
- Create a recovery branch from the current protected branch tip.
- Run revert-the-revert locally.
- Push and open a recovery PR.
- Pass required checks/approvals and merge queue requirements.
- Post final commit hash in incident timeline.
Reapply PR #123 (revert the revert) keeps incident history easy to scan later.
6. Conflict and wrong-target recovery
If revert-the-revert conflicts
# resolve conflicts in editor
git add -A
git revert --continueIf you targeted the wrong rollback commit
git revert --abort
# locate correct rollback hash, then retryIf reapply is no longer fully valid
When architecture moved on since rollback, a fresh PR can be safer than forcing full reapply. Keep only required commits via cherry-pick or manual patching.
7. FAQ
Does revert-the-revert restore everything exactly?
It attempts to reapply the inverse of the rollback commit. If surrounding code changed, you may need conflict resolution before it matches desired state.
Can I do this from GitHub UI only?
Sometimes. If GitHub offers a Revert button for the rollback commit or PR, UI is fine. For complex conflicts, CLI is more reliable.
Should I reset instead for speed?
Not on shared branches. Reset + force-push rewrites history and can disrupt teammates and CI pipelines.
How do I explain this in incident review?
Reference three hashes: original PR merge, rollback commit, and reapply commit. This makes timeline and causality explicit.
Where should I learn merge-parent details?
Use Git Revert a Merge Commit for -m parent strategy and re-merge edge cases.