How Git Works Internally: Blobs, Trees, Commits and Refs

Overview

This introductory video explains what happens behind everyday commands such as git add and git commit. Rather than just a version control system, it describes Git as a huge key-value store for tracking content. The key is a 40-character SHA-1 hash computed from the content itself: the same content always gives the same key, and changing one character gives a completely different one, as running git hash-object on “hello” shows.

Key Points

• Git stores three kinds of objects. A blob holds only a file’s contents, not even its name. A tree maps names, modes and types to hashes and can point to other trees. A commit points to one tree, a snapshot of the whole project, plus the author, time, message and its parent. History is simply this chain of commits.
• In .git/objects, each hash is split into a two-character folder name and a 38-character file name so that no folder grows too large.
• git add moves files from the working directory into the staging area (the index), and git commit stores them as a snapshot in the repository.
• A branch is just a small file under refs/heads holding one commit hash, so creating one is instant. HEAD normally points to a branch rather than a commit, and a tag is a reference that never moves.
• Because blobs carry no names, files with identical content share a single blob, and unchanged files keep pointing to existing blobs. This is what keeps Git efficient.

Chapters

• 0:00 Introduction
• 0:10 Git is a key-value store
• 1:03 Trying it out
• 1:26 Only three kinds of boxes
• 1:37 Box one: the blob
• 2:19 Box two: the tree
• 3:16 Box three: the commit
• 4:29 Inside the .git folder
• 5:30 Working tree, staging area and repository
• 7:04 What branches and HEAD really are
• 9:47 How deduplication works
• 11:29 Summary
• 12:33 Ending