Going back to an earlier version
The undo button you get once your work is in Git
The short version
Once you have committed your work, you can get earlier versions of it back. That is the single most useful everyday benefit of version control, and it is the reason the commit habit is worth building before you need it.
Almost everything you will want lives in two tabs of GitHub Desktop:
- the Changes tab, for work you have not committed yet, and
- the History tab, for everything you have.
Find the file or the commit, right-click it, and read the menu. That is the whole navigation pattern — the specific options are described below and in GitHub’s own documentation, which stays current with the app in a way a screenshot on this page would not.
Why this page exists
M02 makes a promise about version control: that you can “scroll back through the list of checkpoints, see exactly what changed at each one, and return to any earlier version of any file.” This page is where that promise gets cashed in.
You do not need it in Week 1. Keep it bookmarked for the afternoon you need it — and you will know the afternoon when it arrives.
One thing to understand before anything else. Git’s version history can only take you back to states you committed. Work you never committed has no earlier version in Git to return to, because none was ever recorded. That is not a limitation to work around; it is the reason to commit at the end of a working session even when nothing is finished. A commit is cheap. Losing an afternoon is not.
Three situations, in order of how often they happen
1 · “I broke something I haven’t committed yet”
By far the most common. You changed a chunk that worked, and now it doesn’t, and you want the version from an hour ago.
In the Changes tab, GitHub Desktop lists every file you have modified since your last commit. Click one and the right pane shows exactly what you changed, line by line — deletions in red, additions in green. Often that display alone solves the problem: you can see the three lines you broke and type them back.
If you want to abandon your changes to a file entirely, right-click the file in the Changes list and look for the discard option. That returns the file to the state it was in at your last commit.
Discarding is different from committing
Discarding removes the uncommitted changes from your working file, so Git itself cannot restore them from your commit history — they were never in it. GitHub Desktop does, however, place discarded changes in a dated file in your computer’s Trash, where you can recover them until the Trash is emptied.
Still, treat Discard changes carefully. Read the confirmation dialog before clicking it. If you are uncertain, make a copy of the file first rather than relying on recovery later — or commit the broken version with a message like broken attempt, keeping for reference and go back from there.
2 · “I want to see what this looked like last Tuesday”
Click the History tab. Every commit you have made is listed, newest first, each with the message you wrote and the date.
Click a commit and the right pane shows what changed in that commit — a diff, not a complete copy of the file as it stood that day. That distinction matters, and in practice the diff is usually all you need: scroll backward until you find the change you are looking for, read what the earlier code or text was, and restore that into your current file.
This is the moment your commit messages either help you or don’t. A history of update, stuff, final2 gives you nothing to navigate by; you end up opening commits one at a time hoping to recognize the right one. Add age-group recode and Fix denominator in Table 1 let you go straight to it. That is the real reason the labs keep asking for meaningful messages — not etiquette, but your own future convenience.
3 · “I want to undo a commit I already made”
The deciding question is whether you have pushed it. If not, use Undo; if you have, use Revert. Both are below.
Find the commit in the History tab, right-click it, and choose the revert option.
Reverting does not erase history. It creates a new commit that undoes the changes from the old one. Both commits stay in the record — which is exactly what you want on a shared project, because your teammates’ copies of the history remain valid. Nothing they have disappears out from under them.
If you have just committed and have not pushed yet, there is a simpler option: GitHub Desktop offers Undo at the bottom of the Changes tab. Undoing restores that commit’s changes to your working directory, so you can edit them and commit again — as if you had not committed in the first place.
→ Reverting a commit in GitHub Desktop → Undoing a commit in GitHub Desktop
A caution for the group projects
On a shared repository, prefer reverting to anything that rewrites history. Reverting adds a commit; rewriting removes or changes commits your teammates may already have pulled, and that is how a team ends up with three incompatible versions of the same project.
The Collaborating with Git page says the same thing more strongly about force-pushing, and for the same reason. If you find yourself reading instructions that involve rewriting shared history, that is the moment to ask rather than proceed.
What Git cannot give back
Worth knowing the boundary, so you do not go looking for something that was never there:
| Uncommitted work | Not in Git history, so Git cannot restore an earlier version of it. If you discarded it through GitHub Desktop, check your computer’s Trash before giving up |
| Unpushed commits | A real commit with full local history — safely recorded on your laptop, just not copied to GitHub yet, so teammates cannot see it |
Files excluded by .gitignore and never committed |
Not stored in Git history. For course data, re-obtain from the documented source |
That last row is deliberate, not an oversight — M02 explains why data stays out of the repository. It does mean your recovery plan for data is documentation/data-provenance.md, not GitHub.
If something has gone badly wrong
Stop before you try to fix it. The most common way a recoverable situation becomes an unrecoverable one is a hurried attempt at repair.
Copy your whole project folder somewhere else first — a plain duplicate on your desktop, before you touch anything. Then bring it to lab or office hours. Git problems are almost always fixable, and they are much easier to fix from a state that has not been improvised on.
Going further
- GitHub Desktop documentation — concise per-feature articles, kept current with the app.
- Happy Git with R by Jenny Bryan and the STAT 545 TAs — the friendliest full treatment of Git for R users, including a chapter on getting yourself unstuck.