Finding a previous version of your file on GitHub

To see what a file looked like at an earlier point, go to the file in your repository on GitHub.com, click the History button (it looks like a clock icon) in the top right of the file view, and you will see a list of every change made to that file, with the most recent at the top. Each entry shows who made the change, when they made it, and the message they wrote to describe it. Click any entry to see exactly what the file contained at that moment.

The History view shows you the commit — the snapshot of your work at that point in time. You are not changing anything by looking; you are only viewing. This is the safest way to browse your past work because nothing happens to your current version until you decide to restore it.

Key Takeaways

  • Click the History button on any file to see a list of all changes, with the most recent at the top.
  • Each history entry shows who changed the file, when, and why they made the change.
  • Click a commit to see the exact contents of the file at that moment in time.
  • You can restore an old version by copying its contents or by using the command line to revert your entire project to that commit.
  • Restoring a previous version creates a new commit that records the restoration, so your full history remains visible.

What you see when you click on a commit

When you click a commit in the history, GitHub shows you a diff — a side-by-side view of what changed. The left side (usually in red or pink) shows the old version; the right side (usually in green) shows the new version. Lines that were deleted appear on the left, lines that were added appear on the right, and lines that stayed the same are often hidden to save space.

At the top of the diff, you will see the commit message — the explanation the person who made the change wrote. This message is your best clue for understanding why the change happened. Below that is the date, time, and the name of the person who made it. If you need to know more, you can click their name to see all the commits they have made.

Restoring a file to an older version

If you want to bring back an old version of a file, you have two main paths: copy the contents manually, or use the command line to revert the commit. The manual path works well if you only need to restore one file and you are comfortable copying and pasting. Open the old version in the history, select all the text, copy it, go back to your current file, paste it in, and commit the change with a message like "Restore file to version from [date]".

The command line path is faster if you know how to use Git. Open your terminal, navigate to your project folder, and run git revert [commit-hash], replacing [commit-hash] with the long string of letters and numbers shown next to the commit you want to undo. Git will create a new commit that reverses the changes from that old commit. This method keeps a clear record that you intentionally reverted something, rather than making it look like you just edited the file.

Understanding commit hashes and why they matter

Each commit has a unique identifier called a hash — a long string of letters and numbers like a3f8d2e9c1b4. GitHub shows you the full hash and a shortened version. The hash is how Git knows which exact moment in time you are talking about. When you restore a file or share a link to a specific version, you are using the hash to point to that one commit out of potentially thousands.

You do not need to memorize hashes. GitHub lets you click to copy the hash, and you can also click the hash itself to see the full commit page, which shows all the files that changed at that moment, not just one. This is useful when you need to understand the bigger picture — what else changed when this particular file was modified.

Viewing changes between two different versions

Sometimes you want to see what changed between two specific points, not just look at one commit. In the History view, you can click the first commit you want to compare, then hold Shift and click the second commit. GitHub will show you all the changes that happened between those two moments. This is useful when you are trying to figure out when something broke or when a particular feature was added.

You can also compare versions using the command line by running git diff [hash1] [hash2], which shows the differences between any two commits. The order matters — the first hash is treated as the "before" and the second as the "after". If you reverse them, you will see the same changes but with the colors flipped (additions become deletions and vice versa).

Why your full history stays visible even after restoring

When you restore an old version, you are not erasing the commits that came after it. Instead, you are creating a new commit that says "go back to how things were." This means your history looks like a timeline: old version, newer changes, even newer changes, then a commit that says "restore to old version." Everyone can see the full story of what happened and when.

This is different from straightforward deleting the newer commits, which would erase the record that they ever existed. Keeping the full history is important because it lets you and your team understand why decisions were made and what was tried before. If you restore something and then realize it was a mistake, you can restore the version that came after it just as easily.

Frequently Asked Questions

Can I restore just one file without affecting the rest of my project?

Yes. Copy the old version of the file from the history, paste it into your current file, and commit the change. This restores only that one file. If you use the command line method with git revert, it will undo all changes from that commit, which might affect multiple files if they were all changed at the same time.

What if I restore a version and then change my mind?

Your restoration is just another commit, so you can undo it the same way you undid anything else — by viewing the history and restoring the version that came before your restoration. Nothing is ever truly gone as long as the commit exists in your history.

Can I see who changed each line of a file?

Yes. On the file page, click the three dots menu and select Blame. This shows you the most recent commit that touched each line, along with the person who made it and when. It is useful for understanding why a particular line exists or finding who to ask about a specific change.

Does restoring an old version delete the commits in between?

No. When you restore an old version, you create a new commit that reverses the changes. All the commits in between remain in your history. This keeps a complete record of everything that happened, which is important for your team to understand the project's evolution.

How far back can I go in the history?

As far back as your repository exists. If your project has been on GitHub for five years, you can view and restore any version from those five years. The only limit is the storage space GitHub provides, which is very large for most projects.