Part III: Chapter 3.2

git add

The Staging Area

Many people think git add simply tells Git "remember this file for the next commit." That is completely wrong! git add performs heavy lifting immediately. When you run it, Git reads the file's contents, compresses it into a permanent Blob object, and saves it into the database before you even commit.

Under the Hood

Click the button below to see the two-step process Git takes when you stage a file.

Working Directory

index.js

console.log("hello");

function test()

Inside .git/

objects/ (Database)

Empty

index (Staging Area)

Empty

Step 1: Creating the Blob

Git doesn't wait for a commit to save your data. When you run git add, it calculates the SHA-1 hash of the file's contents, creates a compressed Blob, and stores it directly into the .git/objects/ directory.

If you edit the file again and run git add again, Git will create an entirely new Blob object for the new version, even though you haven't committed anything yet!

Step 2: Updating the Index

The "Staging Area" isn't a folder where files are copied. It is simply a single binary file located at .git/index.

Git updates this index file to map the human-readable filename (e.g. index.js) to the cryptographic hash of the Blob it just created. When you finally run git commit, Git just grabs whatever is written in the index and turns it into a Tree object.

Proving the Architecture

We can use low-level plumbing commands to look at exactly what git add does behind our backs.

Terminal

$echo "hello" > test.txt

$git add test.txt

$# Use ls-files to inspect the Staging Area index:

$git ls-files --stage

100644 ce013625030ba8dba906f756967f9e9ca394464a 0 test.txt

$# Notice that ce01362 is a real blob in the database!

$git cat-file -p ce01362

hello