Day 03/13 of Git 101 Series
Concept explanation
Git’s workflow is built on three layers. Working tree is your actual filesystem. Index is a binary staging table that defines exactly what the next commit will contain. Commit is a snapshot stored in the object database.
people think Git commits what’s in your working directory. That is false. Git commits only what the index contains. the index is the gatekeeper between the staged files and history.
Commands
git status git status compares three layers to show what changed. add hashes working tree files into blob objects and updates index entries. commit turns the index into a tree object, writes a commit object, and advances the branch pointer.
Example
You edit three files: A, B, C. You want only A and C in your next commit. git add A git add C git commit -m partial snapshot B stays modified in your working tree but never enters history because its index entry wasn’t updated. that’s controlled commits in practice.
Real world use case
when you’re working on a large feature and accidentally change unrelated files, the index lets you commit only the correct parts. if you fix a bug but also touch formatting, you can stage the bug fix alone and leave formatting changes uncommitted. if you refactor an API and tweak a comment, you choose what enters history. the index is a controlled system, not a dump truck.
Underhood Explanation
Working tree
this is plain files on disk. Git checks them by hashing their contents. nothing in the working tree automatically becomes part of Git’s history.
Index
Stored at .git/index as a binary file. It contains entries with: • path • file mode • object ID (hash of the blob) • mtime and size • flags Each entry points to a blob in .git/objects. git add works by hashing the file’s content, writing a blob object if needed, and updating the index entry to reference that blob. The index is effectively a draft tree of the commit you’re about to make.
Commit
when you run git commit, Git completely ignores your working tree. it converts the current index into a tree structure. it writes tree objects recursively, then writes a commit object that: • points to that tree • points to its parent commit • stores author metadata and message then it moves your branch pointer (refs/heads/main) to this new commit. the only truth Git cares about when committing is the index. the working tree is volatile. the commit is permanent. the index is the computational bridge between the two.
you can read the series of @blogs in here. and i do write a lot in twitter @yswnth
Tomorrow : Day 04/13 of Git 101 Series : Creating a repo (init,clone).