A revision is a saved snapshot of your project at a specific moment in time

In version control systems like Git, a revision is a complete record of every file in your project as it existed at one point. When you commit your work — when you tell Git "save this state" — you create a revision. That revision gets a unique identifier (in Git, a long string of letters and numbers called a hash) so you can refer back to it later, compare it to other revisions, or restore your project to exactly that state.

Think of it like taking a photograph of your entire project folder. Each revision is one photograph. The photograph captures not just what changed, but what everything looked like at that moment. If you made a mistake three commits ago, you can look back at that revision, see what was different, and decide whether to undo the change or learn from what went wrong.

The reason version control systems care about revisions is practical: they let you move backward and forward through your project's history without losing work. You do not have to keep fifty copies of a file named "document_final_v3_REAL_final.txt". Instead, you have one file, and version control remembers every revision of it.

Key Takeaways

  • A revision is a complete saved state of your project, created when you commit changes to version control.
  • Each revision gets a unique identifier so you can reference it, compare it to other revisions, or restore your project to that exact state.
  • Revisions let you move backward through your project history without keeping multiple copies of files.
  • You can see what changed between any two revisions, which helps you understand how your project evolved and find where problems were introduced.
  • Most version control systems store revisions efficiently by recording only what changed, not entire duplicate copies of every file.

How revisions are created and identified

In Git, you create a revision by running a commit command with a message describing what you changed. That commit becomes a revision. Git then assigns it a hash — a 40-character string that uniquely identifies that revision. You can reference the revision by its full hash, by the first 7 characters (which are almost always unique), or by a branch name or tag if you have labeled it.

Other version control systems work similarly but use different terminology. Subversion calls them "revisions" and numbers them sequentially (revision 1, revision 2, revision 3). Mercurial calls them "changesets" and also numbers them. The concept is the same: each one is a saved state of the project, and each one has an identifier you can use to reference it.

The identifier matters because it lets you be precise. If you tell a teammate "I found a bug," they might ask "which version are you looking at?" With a revision identifier, you can say "revision abc1234" and they know exactly what you mean. They can check out that same revision on their computer and see the bug themselves.

What information a revision contains

A revision stores more than just the files themselves. It also stores metadata: who made the commit, when they made it, and the message they wrote describing the change. In Git, you can see all of this by running git log or git show followed by the revision identifier.

The revision also contains a pointer to the previous revision (called the parent commit in Git). This creates a chain: revision B points back to revision A, revision C points back to revision B, and so on. That chain is your project's history. It is how version control knows the order in which changes were made and how it can move you backward and forward through time.

When you compare two revisions, version control shows you the difference between them — which lines were added, which were deleted, which were changed. This is called a diff. Diffs are how you review what someone else changed before merging their work into yours, and how you figure out which revision introduced a bug.

Why you might need to reference a specific revision

The most common reason is debugging. If your code worked last week and is broken today, you can check out the revision from last week, test it, and confirm it works. Then you can move forward one revision at a time until you find the commit that broke it. Once you know which revision caused the problem, you know which change to undo or fix.

Another reason is collaboration. If you and a teammate are working on different features, you each create revisions on separate branches. When you are ready to merge, version control compares the revisions to see if the changes conflict. If they do not, it can merge them automatically. If they do, it shows you exactly where the conflict is so you can resolve it by hand.

You might also need to reference a revision to deploy a specific version to production. Many teams tag important revisions (like "version 1.2.0") so they can easily check out and deploy that exact state of the code months later, even if the main branch has moved on.

How version control stores revisions efficiently

You might think that storing a complete snapshot of your project for every revision would use enormous amounts of disk space. In practice, it does not, because version control systems are smart about storage. Instead of storing a full copy of every file in every revision, they store the differences between revisions.

Git, for example, stores the content of files and uses compression. If you have a file that is 10,000 lines long and you change only one line, Git does not store 10,000 lines twice. It stores the original file and a record of what changed. Over time, Git also runs a garbage collection process that further compresses the history.

This is why a Git repository on your computer is usually much smaller than you might expect. A project with years of history and thousands of revisions might be only a few hundred megabytes, even though the working files themselves are much larger.

Revisions and branches

A branch is a separate line of development, and each branch has its own sequence of revisions. When you create a new branch, you are saying "from this revision, I want to develop in a different direction." The new branch starts at that revision and moves forward from there.

This is why branches are powerful. You can have one sequence of revisions on your main branch (the stable, production-ready code) and a completely different sequence on a feature branch (experimental code you are still working on). Each branch remembers its own history. When you merge the feature branch back into main, you are combining the two histories.

If you switch between branches, you are switching between different revisions. When you check out the main branch, your working files change to match the latest revision on main. When you check out a feature branch, your files change to match the latest revision on that branch. This is why version control can switch your entire project state with a single command.

Common tasks involving revisions

To see the history of revisions on your current branch, run git log. This shows you a list of revisions with their hashes, authors, dates, and commit messages, newest first.

To see what changed in a specific revision, run git show followed by the revision hash. This shows you the commit message and the diff — exactly which lines were added, deleted, or changed.

To restore your project to a previous revision, run git checkout followed by the revision hash. This updates your working files to match that revision. (Note: this puts you in a detached state, meaning you are not on a branch. If you want to keep changes, you should create a new branch.)

To compare two revisions, run git diff followed by two revision hashes. This shows you all the differences between them.

To undo a revision without erasing it from history, run git revert followed by the revision hash. This creates a new revision that reverses the changes from the old one. This is safer than deleting history because it keeps a record of what happened.

Frequently Asked Questions

Can I delete a revision?

Technically yes, but you should rarely do it. Deleting a revision erases it from history, which can confuse teammates and break things if other revisions depend on it. If you made a mistake, it is safer to create a new revision that undoes the mistake (using git revert) so the history stays intact and everyone can see what happened.

What is the difference between a revision and a branch?

A revision is a single saved state of your project. A branch is a sequence of revisions moving forward from a starting point. You can think of a branch as a timeline, and each revision as a moment on that timeline. You can have many branches, each with its own sequence of revisions.

If I check out an old revision, will I lose my current work?

If you have uncommitted changes, Git will warn you and refuse to switch until you commit or discard them. If you have committed your work, you can switch to any revision without losing anything — your commits are saved. Switching revisions just changes which revision your working files match.

Why do revision hashes look like random letters and numbers?

They are not random — they are generated by a mathematical function (SHA-1 in Git) that creates a unique identifier based on the content of the revision. This ensures that the same content always produces the same hash, and different content produces different hashes. It also makes it nearly impossible for two different revisions to have the same hash by accident.

Can two people create the same revision?

No. Even if two people make identical changes, if they commit at different times or on different computers, the timestamps and metadata will be different, so the hashes will be different. The revisions will have the same code but different identifiers.