Git is a distributed version control system — a tool that tracks changes to files over time, allowing you to recall specific versions later, collaborate with others, and recover from mistakes. It is the most widely used version control system in the world and is a foundational tool in modern software development.
Before understanding what Git is, it helps to understand the problem it solves.
The Problem: Managing Change
Every developer, at some point, has manually saved versions of their work — creating files like app-v1.js, app-final.js, app-final-FINAL.js. This approach works until it doesn't: you forget which version has which change, you accidentally overwrite something important, or a colleague's changes conflict with yours and there is no clean way to reconcile them.
Version control systems were built to solve this problem systematically.
A Brief History of Version Control
Version control has evolved through three generations, each solving limitations of the previous:
Local Version Control Systems
The earliest approach was purely local — a simple database on your own machine that tracked changes to files. The tool RCS (Revision Control System) is a classic example. It worked by storing patch sets (the differences between file versions) so it could reconstruct any version on demand.
The limitation was obvious: everything lived on one machine. Collaboration was impossible, and losing that machine meant losing everything.
Centralised Version Control Systems (CVCS)
The next generation introduced a central server that held all versioned files. Tools like CVS, Subversion (SVN), and Perforce followed this model. Developers checked files out from the central server, made changes, and checked them back in.
This enabled collaboration, but introduced a critical weakness: the central server was a single point of failure. If the server went down, nobody could collaborate or save changes. If the server's disk was corrupted and backups were inadequate, the entire project history was gone.
Distributed Version Control Systems (DVCS)
This is where Git and systems like it belong. In a distributed system, every developer has a full copy of the entire repository — including its complete history — on their local machine. There is no single point of failure.
If a server goes down, any client repository can restore it. Every clone is effectively a full backup. Work can continue entirely offline, and changes are synchronised when a network connection is available.
This model is fundamentally more resilient, faster, and more flexible than anything that came before it.
A Short History of Git
Git was created in 2005 by Linus Torvalds — the same person who created the Linux operating system. The circumstances of its creation are worth knowing.
From 1991 to 2002, changes to the Linux kernel were shared as patches and archived files. In 2002, the project adopted a proprietary DVCS called BitKeeper. In 2005, the relationship between the Linux development community and BitKeeper's commercial owner broke down, and the free licence was revoked.
Linus Torvalds responded by building a new system from scratch, guided by specific goals:
- Speed — operations should be fast, even on large projects.
- Simple design — the core should be clean and minimal.
- Strong support for non-linear development — thousands of parallel branches running simultaneously.
- Fully distributed — no central authority required.
- Able to handle large projects efficiently — the Linux kernel itself being the benchmark.
Git was released in 2005 and has since become the industry standard for version control — used by individuals, startups, and companies like Google, Microsoft, and Meta.
What Makes Git Different
Beyond being distributed, Git has several characteristics that distinguish it from other version control systems.
Git Thinks in Snapshots, Not Differences
Most version control systems store data as a list of file-based changes — they record what changed in each file over time. This is called delta-based version control.
Git does not work this way. Every time you save the state of your project (a commit), Git takes a snapshot of what all your files look like at that moment and stores a reference to that snapshot. If a file hasn't changed, Git doesn't store it again — it just stores a link to the identical file already stored. Git thinks of its history as a stream of snapshots, not a stream of differences.
This distinction has deep implications for how Git's branching and merging work, and is a large part of why Git is so fast.
Nearly Every Operation Is Local
Because your machine holds a complete copy of the repository including its full history, most Git operations require no network connection at all. Browsing history, comparing versions, creating branches — all of this happens locally and almost instantaneously.
In systems like Subversion, viewing the project history requires a request to the server. In Git, it's a read from your local disk. This makes Git feel dramatically faster, and means you can work fully offline on a plane, without WiFi, or without VPN access.
Git Has Integrity
Everything stored in Git is checksummed before it is stored, using a mechanism called a SHA-1 hash — a 40-character string derived from the contents of a file or directory. You will see these hashes everywhere in Git:
24b9da6552252987aa493b52f8696cd6d3b00373
This means it is impossible to change the contents of any file or commit without Git knowing about it. Data corruption or silent modification is detectable at the lowest level.
Git Generally Only Adds Data
Almost every action you take in Git adds data — it rarely removes or overwrites anything. Once you commit a snapshot, it is extremely difficult to lose. This makes Git safe to experiment with. You can try things, break things, and know that your committed history remains intact.
What Git Is Used For
Git is most commonly associated with code, but it can track changes to any file. In practice, it is used for:
- Source code — tracking every change to a codebase across a team.
- Configuration files — managing server or application configurations.
- Documentation — versioning technical writing and READMEs.
- Design assets — some teams track binary files like design documents.
In software development specifically, Git is the infrastructure behind collaboration. Every feature, bug fix, and release is managed through it.
Git and GitHub Are Not the Same Thing
This is one of the most common points of confusion for beginners.
Git is the version control tool — the software that runs on your machine and tracks changes. It has no dependency on the internet or any external service.
GitHub is a hosting platform built on top of Git — a website where you can store Git repositories remotely, collaborate with others, and manage projects. GitHub is one option among several (GitLab, Bitbucket, and others also exist).
Git can be used entirely without GitHub. GitHub cannot exist without Git. They are related but distinct.
Why Every Developer Needs Git
Git is not an optional tool. It is the standard infrastructure of software development. Whether you are working alone or on a team of hundreds, you will use Git to:
- Track what changed, when, and why.
- Collaborate without overwriting each other's work.
- Experiment safely on branches without affecting stable code.
- Roll back mistakes to a known working state.
- Understand the full history of a project.
Everything in the Git topics that follow builds on the foundation established here.
The Git research series on this platform is based on Pro Git by Scott Chacon and Ben Straub — the official, comprehensive Git reference. It is available for free at git-scm.com/book.