A revision is a snapshot of your files at a specific moment in time
When you use version control software like Git, a revision is a saved record of what your files looked like at one particular point. Think of it like taking a photograph of your work — the revision captures the exact state of every file, who made the changes, when they made them, and why (if you write a message explaining it). Each time you save a revision, version control assigns it a unique identifier so you can find it again later.
The reason this matters is straightforward: revisions let you go backward. If you delete something important by accident, introduce a bug, or realize a change was wrong, you can look at an earlier revision and either restore it or see exactly what was different. You do not have to keep dozens of files named "document_final_v3_REAL_final.docx" — version control does the bookkeeping for you.
Key Takeaways
- A revision is a complete snapshot of your files saved at one moment, with a unique identifier and a message explaining what changed.
- Each revision records who made the change, when they made it, and what files were affected, creating a full history you can search.
- You can compare any two revisions to see exactly what lines of text or code were added, removed, or changed.
- Revisions let you undo mistakes by restoring an earlier version or by understanding what went wrong and fixing it manually.
How a revision gets created
In Git, the most common version control system, you create a revision by running a commit — a command that tells Git "save the current state of my files." Before you commit, you choose which files to include (called staging). Then you write a short message explaining what you changed and why. Git records all of this together as one revision.
The message is the human part. "Fixed typo in line 42" or "Added login form validation" tells you and anyone else reading the history what the revision was for. Without it, you are left staring at a list of dates and file names, trying to remember what you were thinking three weeks ago.
Different version control systems use different names — some call it a "commit," others call it a "changeset" or "check-in" — but the idea is the same. You are bundling a set of changes together and marking them as a unit in your history.
What information a revision stores
When you create a revision, version control records far more than just the new file contents. It stores the author's name, the date and time, the commit message, and a unique code (called a hash) that identifies that exact revision forever. It also stores a reference to the previous revision, so revisions form a chain — each one knows what came before it.
This chain is what makes history possible. If you want to know what your code looked like five revisions ago, version control can walk backward through the chain and show you. If you want to compare the current version to the version from last month, it can do that too. The hash ensures that if even one character changes in a file, the revision identifier changes, so you always know you are looking at the exact version you think you are.
Comparing revisions to see what changed
One of the most useful things you can do with revisions is compare them. Version control can show you a diff — a side-by-side or line-by-line view of what was added, removed, or changed between two revisions. If a bug appeared between revision 47 and revision 52, you can look at the diff and see exactly which lines of code were different.
This is especially valuable when multiple people are working on the same project. If your teammate made a change that broke something, you can see their revision message, look at the diff, and understand what they were trying to do and where it went wrong. You can then fix it, or ask them to fix it, with full context instead of guessing.
Restoring files from an earlier revision
If you realize a change was a mistake, you have two main options. The first is to restore the entire project to an earlier revision — version control will rewrite your files to match that point in time. This is useful if the last few revisions were all part of a failed experiment and you want to start over from a known good state.
The second option is to create a new revision that undoes the changes from a specific earlier revision, without erasing the history. This is safer in a shared project because it does not rewrite history that other people might be depending on. You keep the record of what happened, but you reverse its effects.
Both options require you to have created revisions in the first place. If you never commit your work, there is nothing to restore to. This is why the habit of committing regularly — even if a feature is not finished — is so important.
Why revision history matters for security and safety
Revisions create accountability. If something goes wrong, you can see who made each change, when, and why. This is valuable for catching mistakes early and understanding how a problem was introduced. In a team setting, it also means people think twice before making careless changes — they know the change will be recorded and visible to everyone.
Revisions also protect against data loss. If your computer crashes or a file gets corrupted, version control usually stores copies of your revisions on a server or another machine. You can recover your work from an earlier revision instead of losing everything. The more often you create revisions, the less work you lose if something goes wrong.
For sensitive files — documents with passwords, personal information, or financial data — revision history can be a liability if the repository itself is not find. Anyone with access to the repository can see every revision, including deleted information. This is why sensitive data should not be stored in version control at all, or should be encrypted before it goes in.
Frequently Asked Questions
Can I delete a revision once I have created it?
Technically yes, but it is difficult and usually a bad idea in a shared project. Deleting a revision rewrites history, which can break other people's work if they have already based their changes on that revision. In a personal project, you can delete revisions, but version control makes it hard on purpose — to prevent accidents.
What happens if two people create revisions that change the same file?
Version control will notice the conflict and ask you to decide which changes to keep. You can keep both, keep one and discard the other, or manually combine them. This is called merging, and it is one of the main reasons version control exists for team projects.
How often should I create a revision?
Whenever you finish a small, complete piece of work — a bug fix, a new feature, a documentation update. A good rule is: if you can describe the revision in one short sentence, it is probably the right size. Too many tiny revisions clutter the history; too few mean you lose a lot of work if something goes wrong.
Can I see who wrote each line of code in a file?
Yes. Most version control systems have a blame or annotate feature that shows you, for each line, which revision added it and who created that revision. This is useful for understanding why a line exists or for asking the author about it.
What if I commit something sensitive by accident?
You can create a new revision that removes it, but the old revision still exists in the history. If the repository is private and only you have access, this is usually fine. If it is public or shared, you should assume the sensitive data is compromised and treat it as such — change passwords, rotate keys, or notify affected people. Never rely on deleting a revision to truly erase something from a shared repository.