Git explained: how version control works

Git is a distributed version control system that manages versions of source code or any other files. Every developer who uses Git keeps a full copy of the entire project history on their own machine, which makes branching, merging, and offline work fast. Git was created by Linus Torvalds in 2005 for Linux kernel development and has since become the version control system most commonly used by software developers.

What version control is

Version control is the practice of controlling, organizing, and tracking different versions of computer files in history — primarily source code, but any type of file. Without it, coordinating a team means passing files around, keeping backups with names like final-v2-real, and hoping nobody overwrites anyone else's work. A version control system records every change so you can see what changed, who changed it, and when, and return to any earlier state.

Version control systems come in two broad models. Centralized systems such as Apache Subversion keep the history on a single server; clients check out a working copy and talk to the server for history and commits. Distributed systems such as Git, Mercurial, and Bazaar give every developer a local repository with the complete history, independent of network access. The repositories are peers: changes travel between them, and teams usually still keep one central shared copy, but nothing blocks work when the server is unreachable.

The history of Git

Git was born from a licensing dispute. From 2002, the Linux kernel was developed with BitKeeper, a proprietary source-control system whose free license was revoked for Linux in April 2005. BitKeeper's copyright holder claimed that Andrew Tridgell had built SourcePuller by reverse-engineering the BitKeeper protocols. The same incident also spurred the creation of Mercurial.

Torvalds wanted a distributed system he could use like BitKeeper, but none of the free systems available met Linux's needs. He cited a system that took 30 seconds to apply a patch and update metadata — at the scale of kernel development, where synchronizing with fellow maintainers could require 250 such actions at once, that did not scale. His requirements: patching should take no more than three seconds, take CVS as an example of what not to do, support a distributed BitKeeper-like workflow, and include strong safeguards against corruption.

Development began on 3 April 2005. Torvalds announced the project on 6 April and the next day Git was already hosting itself. On 29 April, the young system was benchmarked recording patches to the kernel tree at 6.7 patches per second; on 16 June it managed the Linux 2.6.12 release. Torvalds handed maintenance to Junio Hamano on 26 July 2005, who released Git 1.0 on 21 December 2005. As for the name, Torvalds quipped: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'" — the word is British slang for an unpleasant person. The man page calls Git "the stupid content tracker".

How Git stores history: snapshots, not file deltas

Older systems like SCCS and RCS saved space by storing versions of individual files as deltas. Torvalds rejected that model. Git snapshots the whole directory tree: each commit records the complete state of the project, and files that did not change are reused by reference. This is why Git operations are so fast — diffing a big repository is an order of magnitude faster than the older systems, and reading history from a local repository can be a hundred times faster than fetching from a remote server.

Git stores everything in a content-addressable object database. Objects are named by a SHA-1 hash of their contents, and each commit's hash depends on the entire history leading up to it, in a structure similar to a Merkle tree. Once history is published, changing an old version is noticed immediately — that is the safeguard against corruption, accidental or malicious. Torvalds has said he designed Git as "a filesystem" more than a traditional source-control system.

There are four types of objects:

• Blob — the content of a file, with no name, timestamp, or other metadata.
• Tree — a directory: a list of file names and references to blobs or other trees.
• Commit — links trees into history: a tree, timestamp, log message, and zero or more parent commits.
• Tag — a fixed reference to another object, often a signed commit for a release.

Branches are the trick that makes Git's non-linear workflows practical: a branch is just a named reference to one commit, and committing on top of it moves the reference automatically. Creating a branch is nearly free, so thousands of parallel branches on different computers are a design goal, not a burden.

The basic workflow: three states, five commands

In Git's terminology, a file lives in one of three places: the working tree (files you edit), the index (also called the staging area — your next commit, selected with git add), and the repository (committed history). The flow is short:

• git init — create a repository in the current directory.
• git add [file] — stage a file into the index.
• git commit -m [message] — record the staged files as a new commit in history.
• git log — see the history of commits.
• git status — see what has changed and what is staged.

To share work, clone a repository with git clone [URL], pull others' changes with git pull, and publish yours with git push. Because every clone holds full history, most operations work offline. Files listed in a .gitignore file are not tracked by Git — a plain text file that typically lists build output, dependencies, and secrets.

Merging and pull requests

Git implements several merge strategies, selected automatically or at merge time: resolve (classic three-way merge), recursive (the default when merging one branch — when multiple common ancestors exist, it builds a merged tree of them first, which Torvalds reported results in fewer merge conflicts), and octopus (default when merging more than two heads). When changes conflict, Git stops and asks you to edit the conflicting files manually, then completes the merge.

Git itself has no pull request. A pull request — "please merge my branch into yours" — is a feature of hosting services like GitHub, GitLab, and Bitbucket. Under the hood it is no different from a repository maintainer pulling changes from another remote; the hosting service just wraps that operation in a ticket with review, discussion, and status checks.

Git and GitHub

GitHub is a proprietary developer platform that uses Git to provide version control, plus access control, bug tracking, task management, continuous integration, and wikis. It was developed by Chris Wanstrath, P. J. Hyett, Tom Preston-Werner, and Scott Chacon, and launched in April 2008. GitHub grew from 1 million repositories in 2010 to more than 5 million by January 2013, when it passed 3 million users; by the end of 2013 it hosted 10 million repositories. On June 4, 2018, Microsoft announced it would acquire GitHub for US$7.5 billion; the deal closed on October 26, 2018, and GitHub continued to operate independently. In January 2019 GitHub began offering limited free private repositories, and in April 2020 it made all core features free, including private repositories with unlimited collaborators.

GitHub is not the only forge. The same Git protocol is served by GitLab, Bitbucket, and SourceForge, and self-hosted options like Gitea and Forgejo. You can also run your own Git server — Git ships with git daemon, a simple TCP server for the Git protocol (default port 9418), and repositories can be served over SSH or HTTPS.

How widely is Git used?

Git is the most popular distributed version control system, and the most widely used source-code management tool among professional developers. In Stack Overflow's annual developer surveys, Git was the overwhelming favorite among respondents who use version control, reporting as high as 93.9% in 2022 — and Wikipedia cites a figure of nearly 95% of developers reporting Git as their primary version control system as of 2022.

Git vs centralized systems

Subversion, created by CollabNet in 2000 as an open-source successor to CVS, uses a centralized model: the history lives on one server, revision numbers are global, and clients hold a working copy that talks to the server for most operations. Git's local full-history model is the fundamental difference — branch, commit, and explore history without asking anyone's permission.

FAQ

Is Git the same as GitHub?

No. Git is a version control system — a tool you run locally. GitHub is a proprietary developer platform that hosts Git repositories and adds features like pull requests, issue tracking, and CI. Alternatives include GitLab, Bitbucket, SourceForge, and self-hosted options like Gitea and Forgejo.

Is Git free?

Yes. Git is licensed under the GNU General Public License version 2 (GPL-2.0-only, since 11 April 2005, with some parts under compatible licenses). GitHub, the hosting service, is proprietary software that is free for public repositories and for private repositories on its free tier.

Do I need a server to use Git?

No. A Git repository works fully on one machine: git init, commit locally, and every clone is a complete backup of history. A server or hosting service is only needed to share work between people — git daemon, SSH, or HTTPS will do, and forges like GitHub add collaboration features on top.

What is a pull request?

A pull request is a request by a user to merge a branch into another branch, managed by a hosting service. It is not a feature of Git itself — Git only provides the underlying mechanics of pulling changes between repositories.