Cloud Parts

Git

The distributed version control system almost everyone uses: every clone holds the full history, stored as objects named by the hash of their content.

What it is
Version control
Type
Open source
Made by
The Git project (Software Freedom Conservancy)
License
GPLv2
Facts checked
6 October 2026
Website Source code

What it is

At its core Git is a content-addressed object store, a key-value database where the key is a hash of the value. A file’s contents become a blob, a directory listing of blobs and subdirectories becomes a tree, and a commit records one top-level tree (a snapshot of the whole project), its parent commits, the author and the message. Each object is named by its hash, SHA-1 by default, so identical content is stored once and any corruption is detectable. Branches and tags are just refs: small names that point at a commit’s hash. New objects are written as individual compressed files; git gc later packs them into packfiles, storing similar objects as deltas of one another.

Because every clone has every object, nearly everything (commit, branch, merge, log, diff, blame) runs locally, and git push and git fetch only exchange the objects the other side lacks. Linus Torvalds wrote Git in April 2005 for the Linux kernel; Junio C Hamano has maintained it since July 2005, and it is a member project of the Software Freedom Conservancy, licensed under GPLv2 only. In Stack Overflow’s 2022 survey, 94% of respondents used it, and it underlies GitHub, GitLab, Bitbucket, Azure Repos and AWS CodeCommit.

Git is in the middle of moving from SHA-1 to SHA-256. Since 2.13 (2017) it uses a SHA-1 variant that detects known collision attacks, and since 2.29 (2020) git init --object-format=sha256 creates SHA-256 repositories, which can’t yet exchange objects with SHA-1 ones. The planned Git 3.0, which has no release date, will make SHA-256 the default for new repositories once forges and libraries support it, switch the default ref storage to reftable, name the first branch main, and require Rust to build. The latest release is 2.56.0 (September 2026).

Why teams pick it

  • Works offline: commits, branches, history and blame need no server, and every clone is a full backup
  • Branches are a pointer to a commit, so creating and switching them is nearly instant
  • Content hashes make history tamper-evident and deduplicate identical files
  • The common language of the industry: every major host, CI service and IDE speaks it

Watch out for

  • Large binary files bloat every clone forever; use Git LFS or keep them out of the repository
  • Anything committed, secrets included, stays in the history until it is rewritten everywhere
  • Read access is per repository: anyone who can clone gets all of it, unlike Subversion’s per-path permissions
  • SHA-256 repositories can’t yet interoperate with SHA-1 ones, so most of the ecosystem still uses SHA-1

How it fits with other technologies

Look inside the object store · bash

printf 'hello\n' | git hash-object --stdin   # ce013625030ba8dba906f756967f9e9ca394464a

git cat-file -t HEAD            # commit
git cat-file -p HEAD            # tree <hash>, parent <hash>, author, message
git cat-file -p 'HEAD^{tree}'   # the snapshot: blobs and subtrees, each by hash

git count-objects -v            # loose objects versus packed ones
git gc                          # pack loose objects into a packfile

git init --object-format=sha256 new-repo   # a SHA-256 repository

The four kinds of object#

Everything in a repository’s history is one of these, named by the hash of its content.

Blob

file contents

The bytes of one file, with no name or permissions. Two files with the same contents anywhere in history share one blob.

Tree

a directory

A list of names, modes and the hashes of blobs and subtrees. A change deep in a directory creates new trees up to the root; unchanged subtrees are reused.

Commit

a snapshot

Points to one root tree, plus zero or more parent commits, the author and committer, and the message. Changing any of it changes the hash, and the hash of every later commit.

Tag

annotated

Like a commit for naming a release: a tagger, date, message and a pointer, usually to a commit. Lightweight tags skip the object and are just refs.

See it in a real stack

No architecture uses Git yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2005–2026

From 2002 the Linux kernel was developed in BitKeeper, a proprietary distributed version control system its maker let the community use free of charge. In April 2005 that relationship broke down. On April 6 Linus Torvalds told the kernel mailing list he would stop using BitKeeper and look for alternatives. He had hoped to switch only once there was a reasonable open-source alternative, and there wasn’t one.

He wrote his own. The first commit, on April 7, 2005, described “GIT, the stupid content tracker”: a content-addressable collection of objects named by their SHA-1 hash, with blobs and trees. On April 16 the kernel itself moved to Git, starting fresh from 2.6.12-rc2 rather than importing 3.2 GB of history. On July 26 Torvalds announced that Junio C Hamano was the new maintainer, and Git 1.0 followed in December.

GitHub opened in 2008, and Git went on to displace Subversion and CVS: in Stack Overflow’s 2022 survey, 94% of respondents used Git and 5% Subversion. Its later history is about keeping the design sound as it grew: Git 2.0 in 2014 changed long-standing defaults, a collision-detecting SHA-1 arrived in 2017 after the SHAttered attack, SHA-256 repositories in 2020, and optional Rust code in 2025.

Why it’s built this way

Name every object by the hash of its content
Torvalds wanted an object database where consistency could always be checked: if an object’s hash matches its content, the data is exactly what was stored. The same hashing deduplicates identical files and trees for free.
Store snapshots, not file-by-file diffs
Earlier tools stored each file as a chain of changes. Git records the state of the whole project in every commit, which makes branching, merging and comparing any two points in history simple, with packfiles recovering the space through delta compression.
Speed and scale for the kernel first
Speed and handling large projects like the Linux kernel efficiently were among Git’s original goals. Doing nearly every operation on the local disk, with no server round trip, was the way to get there.
Keep the patch workflow first-class
Kernel development ran on patches mailed to maintainers, and Torvalds called “individual patches” a keyword. git format-patch and git send-email turn commits into emails, with the subject line as the email subject, and Git itself is still developed on a mailing list.

Timeline

  1. 2005

    First commit April 7; the kernel moves April 16; Junio Hamano maintainer from July; 1.0 in December

  2. 2008

    GitHub opens to the public

  3. 2014

    Git 2.0, a release that deliberately breaks old defaults (May)

  4. 2017

    Git 2.13 makes collision-detecting SHA-1 the default after SHAttered

  5. 2020

    Git 2.28 makes the default branch name configurable; 2.29 adds SHA-256 repositories

  6. 2025

    Git 2.49 adds the first optional Rust code

  7. 2026

    Git 2.56.0 released September 28; Git 3.0 still has no release date

Sources19 · facts checked 6 October 2026

Improve this page on GitHub