A merged GitHub pull request broke production — what does the Revert button on that pull request create?
answer
- It does not write to main directly
- Something new gets opened, not merged
- Branch protection still applies to the rollback
- One squash commit is easier to undo than many
- New branch plus a new pull request titled Revert
basics
~20 sIt creates a new branch and opens a new pull request whose diff undoes exactly what that pull request merged. Nothing is written to the base branch until that revert pull request passes the usual checks and is merged.
solid answer
~50 sThe Revert button does not touch the base branch. GitHub creates a branch off the base, applies the reverse of what the original pull request merged, and opens a **new pull request** titled `Revert "<original title>"`. That revert pull request goes through the same required checks, approvals and merge method as any other change. That indirection is the point: rollback is a normal change, so branch protection stays intact, the rollback is reviewable, and the timeline records who rolled back and why. What gets reverted depends on how the original merged — a squash merge means one commit to undo; a merge commit means the merge itself is undone. GitHub offers the button only when it can compute the revert cleanly. If the surrounding code has moved on, it tells you to do it locally instead. To re-land the change later, you open a further pull request that reverts the revert.
go deeper
Know that GitHub's Revert button opens a new pull request undoing the change rather than editing main directly, and that it still needs review and checks.
Explain what determines the revert's granularity — the merge method used originally — and why GitHub sometimes refuses to compute the revert automatically.
Show incident judgment: revert first and diagnose later, the checks that still gate the rollback, and the follow-ups GitHub does not do such as reopening the linked issue and confirming the deploy actually rolled back.
Own the rollback policy: how fast a revert must be possible, what merge strategy that implies repository-wide, and whether emergency bypass actors should exist at all given that a revert pull request is usually fast enough.
## Rollback as a pull request, not a push The instinct under pressure is to get the bad change off main as fast as possible, and the fastest path looks like a direct push. On a protected branch that path is closed — and it should be, because an unreviewed, unchecked push during an incident is how one outage becomes two. GitHub's Revert button reconciles speed with policy: it prepares the entire rollback for you, but delivers it as a pull request that goes through the same gates as everything else. ## What GitHub actually produces Clicking Revert on a merged pull request creates a new head branch from the current base branch and applies the inverse of what that pull request contributed. It then opens a pull request with a generated title of the form `Revert "<original title>"` and a body referencing the original. From that point it is an entirely ordinary pull request: required status checks run, required approvals apply, code owners are requested if the paths match, and it merges with whichever merge methods the repository allows. What is inverted depends on how the original landed. If the pull request was squash-merged, there is exactly one commit on the base branch representing it, and that is what gets undone — which is one of the strongest practical arguments for squash merging in the first place. If it was merged with a merge commit, the merge is what gets reverted. If it was rebase-merged, the copies that landed are what get reverted. ## When the button is not offered GitHub computes the revert against the current state of the base branch. If subsequent changes have altered the same regions, the revert cannot be applied automatically and GitHub says so, leaving you to construct the rollback locally and open the pull request yourself. Practically this means the value of the button decays with time — reverting something merged an hour ago usually works; reverting something from three weeks ago often does not. That is a good reason to make the rollback decision early rather than debating it while the divergence grows. ## Re-landing afterwards A revert is not a deletion. The original commits remain in history, and the revert adds a change that cancels them. When the underlying bug is fixed and you want the feature back, the workflow is to open a pull request that reverts the revert — typically with the fix included or stacked directly on top. Teams that do this regularly keep the revert pull request's description explicit about *why* it was reverted, because the person re-landing it weeks later is often not the person who rolled it back. ## Things that do not happen automatically - **Linked issues do not reopen.** If the original pull request closed an issue with a keyword, reverting leaves that issue closed. Someone has to reopen it. - **Deployment does not roll back by itself.** Merging the revert triggers whatever your merge-to-deploy path is; if you deploy from tags or need a manual promotion, the revert pull request merging is not the same as production being healthy again. - **The original pull request stays merged.** Its state does not change; the revert is a separate, forward-moving record. ## Interview framing This question is a proxy for "have you handled a bad deploy on a protected branch". A strong answer says: the button opens a pull request rather than pushing, so protection and review are preserved; the granularity of what can be reverted follows from the merge method the repository chose; the automatic revert only works while the surrounding code has not moved; re-landing means reverting the revert; and the human follow-ups — reopening the issue, confirming the deployment actually rolled forward to the reverted state — are yours to remember, because GitHub does not do them for you.
- Why is a revert pull request preferable to pushing a revert commit straight to main during an incident?Because the rollback runs the same required checks and review as any change, so you do not discover that the revert itself is broken in production. It also keeps branch protection intact — no bypass is needed — and leaves an auditable record of who rolled back and why, which the post-incident review will want.
- How does the repository's merge method change what a revert undoes?With squash merging, the whole pull request is one commit on the base branch, so the revert is a single clean inverse. With a merge commit, the merge is what is reverted. With rebase merging, the copies that landed are reverted. Squash merging gives the cleanest one-pull-request-one-rollback granularity.
- After reverting, how do you get the feature back once the bug is fixed?Open a new pull request that reverts the revert, usually with the fix applied on top, and take it through review and checks like any change. Keep the original revert's description explicit about the failure so whoever re-lands it weeks later knows what must be different this time.
saying these in an interview costs you the question
- Thinks Revert pushes straight to the base branch
- Says it deletes or rewrites the original merge commit
- Expects the linked issue to reopen automatically
- Assumes the button always works no matter how old the merge is
- Believes reverting reopens or unmerges the original pull request