How Git Internally Works: A simple guide

**

How Git Works Internally**

Git works by storing files as blobs (content with hashes), directories as trees (listing files), and snapshots as commits (with history links), all in .git/objects. Branches are refs pointing to commits, the index stages changes into trees, and everything is immutable with content-based names for safety and efficiency.

Understanding the .git folder

The .git is the folder where git stores all the information about the git repository: “objects” folder saves files (blobs), folders (trees), and versions or commits by their hash; “refs” folder points branches or tags to versions; HEAD shows where you are; index holds staged files; config sets options; “logs” folder tracks moves; “hooks” folder runs scripts. We should never delete or edit it manually, as it can ruin the whole project.

Git Objects: Blob, Tree, Commit

Git objects are simple: blobs hold contents of the files, trees show structure of the folder, and commits save a full project picture with history details.

Blobs: Raw file data only—no names. Hash = unique ID. Same content = same blob.

Trees: Like a folder list: file names, types, and their blob/tree hashes.

Commits: Point to root tree + parents + who/when/message. Snapshots, not changes.

How Git Tracks Changes

Git tracks changes simply by taking full snapshots of your entire project with every commit, instead of just the edits. Each snapshot is a complete picture of all files at that moment, stored nicely through shared hashes. When you ask for differences—like with git diff or git log -p—Git smartly compares these snapshots to show what changed between them. The process flows through your working files, staging with git add (which prepares the snapshot pieces), and committing to save it permanently.