What Is Version Control?

The problem version control solves

Every IT team has seen it: a shared folder with report_final.docx, report_final_v2.docx and report_final_v3_REAL.docx. Nobody is sure which one is current, what changed between them, or whose edits were lost when two people saved over each other.

In operations the same problem is more dangerous. A colleague edits the configuration of a router or a web server, something breaks at night, and the questions start: what was the configuration yesterday? Who changed this line, and why? If the only copy is the file on the device, and it was overwritten, nobody can answer.

Version control solves this by recording each saved state of a set of files in a repository, together with the author, the time and a message. The overview page Version Control with Git introduces the core ideas — commits, branches, merging and remotes; this topic goes deeper into each of them.

What version control gives you

• A complete history. Every change is kept, not only the latest version. You can see how a file looked on any day, and compare any two versions line by line.
• Who, when and why. Each recorded change carries an author, a timestamp and a message. "Changed NTP server to the new pool, ticket CHG-1042" answers the night-time question in seconds.
• Going back. A bad change can be undone by returning a file, or the whole project, to an earlier state — without anyone having to remember what it was.
• Parallel work. Several people can change the same project at the same time on separate lines of work (branches) and combine the results, with the tool pointing out where their edits collide.
• Review before change. Because every change is a recorded unit, a colleague can review it before it goes live — the basis of pull requests and change enablement.

Centralized and distributed version control

Version control systems differ in one fundamental design choice: where the history lives.

Centralized

In centralized version control, one server holds the only complete history. Each user checks out a working copy of the files, and every commit, log query or comparison with an older version is a request to that server. Well-known examples are CVS (Concurrent Versions System), Apache Subversion (SVN) and Perforce (still common for very large game and media projects). The model is simple and gives the administrator central control, but no server means no commits, and a lost server without backups means a lost history.

Distributed

In distributed version control, every copy of the repository contains the full history. You commit, browse the log, compare versions and create branches on your own machine, without a network, and exchange commits with other copies when you choose. Git and Mercurial are the best-known distributed systems. A team usually still agrees on one shared copy — on GitHub, GitLab or an internal server — but that is a convention, not a technical requirement: technically all copies are equal.

A short history of Git

Until 2005 the Linux kernel was developed with BitKeeper, a proprietary distributed version control system whose maker offered a free license to kernel developers. In April 2005 that free license was withdrawn after a dispute. Linus Torvalds, the creator of Linux, did not want to go back to patches and tarballs, and no existing free tool was fast enough for a project of that size, so he wrote his own. Within weeks the kernel was managed in it. Mercurial was started in the same month for the same reason.

Git is the free, open source, distributed version control system that came out of this work. Its design goals were speed, a simple internal model, strong support for many parallel branches, and integrity: every object is named by a hash of its content, so corruption or tampering is detected (see How Git Stores Your Work). In July 2005 Torvalds handed maintenance to Junio Hamano, who has maintained Git ever since. Hosting services for Git — GitHub from 2008, later GitLab and Bitbucket — made it the default choice for open source and, over the following decade, for most companies.

Git today

Git has a new feature release about every three months. As of October 2026 the latest release is Git 2.56.0 (28 September 2026). The project is preparing Git 3.0, which has no release date; its planned breaking changes include:

• SHA-256 instead of SHA-1 as the default hash for new repositories;
• main instead of master as the default name of the first branch;
• a new default storage format for branches and tags ("reftable");
• Rust becoming a requirement to build Git itself;
• the removal of a few long-deprecated commands and options.

None of this changes the everyday commands on these pages. The examples in this topic run on Git 2.39; where newer versions behave differently, the text says so.

Git and GitHub

Git is a program that runs on your computer. It needs no account, no website and no network. GitHub is a hosting platform, now owned by Microsoft, that stores Git repositories on its servers and adds features around them: a web interface, access control, issues, pull requests and code review, automation with GitHub Actions, and security scanning. GitLab, Bitbucket and Azure Repos offer similar services, and many organizations run their own server.

Everything you learn about Git works the same with any host. What GitHub adds is covered in GitHub Essentials.

What belongs under version control

The rule of thumb: version everything that a person writes and that you need to rebuild or understand the system.

• Source code and the tests that go with it.
• Configuration: router and switch configs, web server and application settings, Ansible inventories.
• Documentation: a README.md, runbooks, architecture notes — next to the code they describe.
• Infrastructure definitions: with infrastructure as code, the files that describe servers and networks are reviewed and versioned like any other code.
• Pipeline definitions: the CI/CD (continuous integration and delivery) workflow files that build and deploy the project (see What Is CI/CD?).

What does not belong in a repository:

• Secrets — passwords, API keys, tokens, private keys. Every clone receives the complete history, and a secret stays in it even after you delete the file. Use a secrets manager or the platform's secret store (see Securing Repositories).
• Generated files — compiled programs, build output, logs, caches. They can be recreated from the source, and they produce noisy, conflicting changes. Exclude them with a .gitignore file (see Staging and Committing).
• Large binary files — disk images, videos, big datasets. Git cannot show a useful difference between two versions, and every version stays in every clone forever. If you must version them, use Git LFS (Git Large File Storage), an extension that stores small pointer files in the repository and the actual content in separate LFS storage, usually provided by the same hosting service.

Revisions

A revision is one recorded version of the project, and also the name you use to refer to it. How a system names revisions follows from its design. Subversion has one central server, so it can simply count: revision 1, 2, 3 … up to r48213. Git has no central counter — two people can commit at the same moment on different laptops — so it names each commit by a hash of its content, such as 2d4218d (the short form of a 40-character hexadecimal string).

In Git, "revision" is the general word for anything that names a commit: a full or short hash, a branch name such as main, a tag such as v1.4.0, or HEAD, the commit you are on now. Expressions such as HEAD~1 ("one commit before the current one") and ranges between two revisions are covered in Exploring History.

A first look at Git

Here is the whole idea in eight commands: create a repository for the network team's tools, add a router configuration, change it, and look at the history. The commands are explained one by one in Your First Repository.

git init -q net-tools
cd net-tools
printf 'hostname R1\ninterface Gi0/0\n ip address 192.0.2.1 255.255.255.0\n' > router.cfg
git add router.cfg
git commit -q -m "Add base config for R1"
printf ' description Uplink to ISP\n' >> router.cfg
git add router.cfg
git commit -q -m "Describe the uplink interface"
git log --oneline
git log --format='%h | %an | %ad | %s' --date=short

2d4218d Describe the uplink interface
5fad0d0 Add base config for R1
2d4218d | Sam Rivera | 2026-03-02 | Describe the uplink interface
5fad0d0 | Sam Rivera | 2026-03-02 | Add base config for R1

The newest commit is listed first. Each line starts with the short hash that names that revision; the second log adds who made the change and when. Run the same commands yourself and your hashes will be different — they depend on your name, email address and the time. The examples on these pages use a fixed author and date, so the hashes shown here are exactly what the commands print.