What is Version Control?
Version control is a system that records every change you make to your files over time, so you can see what changed, who changed it, and go back to any earlier version whenever you need to. If you have ever saved files named report-final.txt, report-final-v2.txt, and report-really-final.txt, you already understand the problem version control solves — except it does the saving, naming, and comparing for you, automatically and safely. For anyone learning DevOps, version control is the very first skill to master because almost everything else (automated builds, deployments, infrastructure code) is triggered by changes you push into a version control system.
What problem does version control solve?
Imagine you are editing the configuration for a web server on an Ubuntu machine. You make a change, the server breaks, and now you cannot remember exactly what the file looked like before. Without version control, your only options are guessing or restoring a backup (if one exists).
A VCS (Version Control System — software that tracks changes to files) fixes this by storing a complete history. Every saved snapshot is called a commit (a recorded point-in-time state of your files, with a message describing what changed). With that history you get three superpowers:
- History — see every change ever made, with timestamps and authors.
- Collaboration — many people can work on the same project at once without overwriting each other.
- Rollback — instantly return any file (or the whole project) to a known-good earlier state.
Version control is not a backup tool. A backup protects you from losing the disk; version control protects you from losing the right version. You still want both.
Centralized vs distributed version control
There are two broad designs for a VCS. Older tools like Subversion (SVN) and CVS are centralized: there is one central server that holds the full history, and your computer only has the files you are currently working on. If that server is down — or gone — nobody can commit, and the history may be lost.
Modern tools, led by Git, are distributed. When you copy a project (this copy is called a clone), you receive the entire history onto your own machine. You can commit, view history, and create branches completely offline. You only need the network to share work with others.
| Feature | Centralized (SVN, CVS) | Distributed (Git) |
|---|---|---|
| Where the full history lives | Only on the central server | On every developer’s machine |
| Works offline | No (need server to commit) | Yes (commit locally anytime) |
| Single point of failure | Yes (the server) | No (every clone is a full copy) |
| Branching speed | Slow, heavyweight | Instant, cheap |
| Industry standard in 2026 | Legacy | Yes — the default everywhere |
When to use which: For any new project, use Git. You would only touch SVN today if you inherited an old codebase that still lives there, and even then most teams migrate it to Git.
How Git tracks your changes
Git is the distributed version control system that has become the universal standard. It is free, open source, and installed on virtually every developer machine and server. Here is the simple mental model.
Git tracks changes in three areas:
- Working directory — the actual files on disk you edit.
- Staging area (also called the index) — a holding zone where you pick exactly which changes go into the next commit.
- Repository — the
.gitfolder that stores the permanent committed history.
A repository (or repo) is just a normal folder that Git is watching. You turn any folder into a repo with one command. Let’s try it on Ubuntu.
mkdir ~/my-project
git init ~/my-projectOutput:
Initialized empty Git repository in /home/ubuntu/my-project/.git/That hidden .git/ directory is the repository — it holds the whole history. Now create a file and record your first snapshot.
cd ~/my-project
echo "Hello DevOps" > notes.txt
git add notes.txt
git commit -m "Add notes file"Output:
[main (root-commit) 4f2a9c1] Add notes file
1 file changed, 1 insertion(+)
create mode 100644 notes.txtgit add moves the change into the staging area; git commit writes it permanently to history with a message. Each commit gets a unique hash (the 4f2a9c1 above — a fingerprint that identifies that exact snapshot). You can now view your history at any time.
git log --onelineOutput:
4f2a9c1 Add notes fileWhy this is the backbone of CI/CD
CI/CD (Continuous Integration / Continuous Delivery — the practice of automatically building, testing, and shipping code) is the heart of DevOps, and it is built directly on top of Git. Here is the flow you will use every day:
- You commit a change and push it (upload it) to a shared repo on a platform like GitHub or GitLab.
- That push triggers an automated pipeline — a series of steps that build your app, run tests, and deploy it.
- If anything fails, you can roll back to the previous commit instantly.
In other words, the commit is the trigger for everything that follows. This is why teams keep not just application code in Git, but also server configuration, Dockerfiles, and infrastructure definitions. When your infrastructure lives in Git, every change to a server is reviewed, versioned, and reversible — the same way code is.
Best Practices
- Commit early and often. Small, focused commits are easier to understand and to roll back than one giant commit.
- Write clear commit messages. Start with a short summary in the imperative mood, e.g. “Add nginx config” rather than “stuff”.
- Never commit secrets. Keep passwords, API keys, and
.pemfiles out of Git — use a.gitignorefile to exclude them. - One change, one commit. Avoid mixing unrelated fixes; it makes history and reviews harder to follow.
- Pull before you push. Get the latest changes from teammates first to avoid surprises.
- Use branches for new work. Keep the main line stable and develop features in isolation.