How to Undo Changes on GitHub

The most viewed Git question on Stack Overflow asks how to undo the most recent commit, and it has been read around nine million times ^[1]. Plenty of the people asking have used Git for years, so if undoing a change has ever made you nervous, you're in good company. Most mistakes on GitHub can be reversed in a few clicks.

Undoing a change in Git rarely means erasing it. The safest approach adds a new commit that cancels the old one, so the history shows both the mistake and the fix. Everyone can see what was undone and why. GitHub supports this with a Revert button on merged pull requests, and most other undo tasks, like bringing back a deleted file or branch, work by reaching into that same history. AI app builders often offer their own undo through checkpoints, which work differently and don't always travel with the repository.

History is the safety net, so the best undo keeps it intact. Version control can bring back almost any version of a project's files, though not everything that lives outside them, such as a database or a deleted account. Knowing that boundary matters as much as knowing where the Revert button is.

Why undoing changes feels risky

Undoing changes is the most searched-for problem in Git. A study of over 80,000 Git questions on Stack Overflow found that the five most-viewed ones were all about undoing something. Only about 14% of the developers surveyed rated themselves proficient, even though most had used Git for five years or more ^[2].

The difficulty isn't a lack of skill. Researchers at MIT who analyzed Git's design argued that much of its complexity points to flaws in that design rather than to its power ^[3]. Several undo commands overlap in confusing ways, which is why people often freeze instead of fixing a mistake.

The browser removes most of that risk. GitHub's undo actions add new commits rather than erasing old ones, so the mistake and its fix both stay visible, and even an undo can be undone.

Reverting a merged pull request

A merged pull request can be undone with its Revert button, near the bottom of the pull request. GitHub then opens a new pull request that reverses the changes the original one merged ^[4].

That second pull request is the undo. It can be reviewed and merged like any other, and once it's merged, the project is back to its earlier state. Both pull requests stay in the history, so anyone can see what was changed, what was reversed, and when.

Reverting works best soon after a merge. If later changes built on the same lines, the revert may run into conflicts that need fixing by hand. It also requires write access, so on a team project, the person who can press the button may not be the one who spotted the problem.

Pro Tip! A revert pull request can be reverted too, which brings the original change back if it turns out to be needed after all.

Reverting vs. rewriting history

There are two ways to undo a commit. Reverting adds a new commit that does the opposite of the old one, so the history shows the mistake and then the fix. Rewriting history removes the old commit as if it never happened, using commands that reset a branch and then force the result onto GitHub.

On a shared branch, rewriting causes real trouble. Teammates who already have the old commit now hold a history that no longer matches GitHub's, and their next sync can bring the removed work back or fail with confusing errors. Rewriting also erases the record of what went wrong.

That's why GitHub's web interface reverts and doesn't rewrite. Rewriting has its uses, like tidying a private branch before anyone else relies on it, but it needs other tools and care. For anything already shared, reverting is the safe and visible choice.

Restoring a deleted file

A deleted file disappears from the current version of a repository, but not from its history. Every commit made before the deletion still contains the file, exactly as it was ^[5].

GitHub has no undelete button, so recovery means reaching into that history. On the repository's commits page, each commit has a button for browsing the repository as it was at that point. Opening a commit from before the deletion shows the file, and its contents can be copied into a new file with the same name and committed. If the deletion was merged through a pull request, reverting that pull request brings the file back in one step.

Clear commit messages make this faster. A commit called Remove old menu page is easy to spot in the history, while one called Cleanup has to be opened to find out what it removed.

Discarding edits before committing

The easiest mistake to undo is one that was never saved. While a file is open in GitHub's web editor, nothing reaches the repository until a commit is confirmed. Cancelling the edit, or simply closing the tab, throws the change away and leaves the file as it was.

The commit dialog works the same way. Closing it without confirming returns to the editor with the edit still in place, which leaves a chance to check the Preview once more or rewrite the commit message.

That makes the commit step a natural checkpoint. Before confirming, it's worth asking two questions: is the change complete, and does it belong on this branch? A few seconds of doubt here saves a revert later, along with the extra history a revert adds.

Restoring a deleted branch

Deleting a branch after its pull request is merged is good housekeeping, and bringing it back is just as easy. The pull request keeps a Restore branch button near the bottom, which recreates the branch ^[6].

That works because deleting a branch removes only its name. A branch is a label pointing to a commit, and the commits themselves stay in the repository, still linked from the pull request that used them. Restoring simply puts the label back.

Branches deleted without a pull request are harder to recover from the browser, since no pull request holds the link to their commits. That's one more reason to make every meaningful branch part of a pull request, even a small one.

AI builder checkpoints vs. Git commits

Many AI app builders offer their own undo, separate from Git. Replit's checkpoints, for example, are snapshots its agent creates automatically, and they capture the app's database contents along with its code ^[7]. Rolling back to one restores everything inside Replit.

Those snapshots live in the builder, not in the repository. A teammate looking at GitHub sees commits, never checkpoints, so a checkpoint can't be reviewed in a pull request or reverted from GitHub.

Both are useful when each does its own job. Checkpoints are quick for undoing a prompt that went wrong. Commits are the shared record a team can see, review, and rely on, so anything worth keeping should reach the repository as a commit, not just as a checkpoint.

What version control cannot undo

Version control protects the files in a repository, and its undo stops there. Anything that lives outside those files has its own history, or none at all.

Things Git can't bring back include:

• Database records deleted by an app or an AI agent
• Account and hosting settings, like domains, plans, or permissions
• Emails, payments, and messages an app has already sent
• Secrets, like API keys, once they've been exposed

Secrets surprise people the most. Deleting a leaked key from a repository doesn't make it safe, because earlier commits still contain it and it may already have been copied. GitHub's guidance is to revoke or rotate the secret first ^[8]. Separate backups and careful permissions protect what a repository doesn't hold.

Asking an AI tool to undo a change

AI app builders and coding agents can undo changes on request, but a vague request gets a vague result. A prompt like undo that leaves the tool guessing what that means, and it may reverse more than intended or rewrite files instead of restoring them.

A good undo request names the change and the method. It points to a specific commit, pull request, or description, like the commit that changed the pricing page, and asks for a revert, which keeps the history intact. It also says what must stay as it is, so unrelated work isn't swept away.

The result deserves the same check as any other change. A study found that non-developers were the only group who reported never checking AI-generated code before using it ^[9], and a quick look at the diff is exactly the habit that closes that gap.

Pro Tip! Asking the tool to show the diff before it applies the undo turns the check into part of the request.