Timing the changes in git

Git as we have learned is a version control system that tracks changes over time. But it was faced with a problem of timing of changes. I mean should it track every letter entered, or a sentence or a function or something else. And this is where it solved it by turned tables around. Instead of git setting standard of timing, it handed over the controls to the user. It is the user that determines the timing of changes. From this arose the concept of staging and committing that we will see below

1. Internal workings of git

Git works by taking snapshots of our project over time and storing them safely inside a hidden folder called “.git”.

Step 1 - Initializing git in the project

git init

To enable tracking changes using git, we must first initialize git in the folder of our project. This is like asking git to start resuming its superpowers.

This command line argument creates a hidden folder named “.git”. It is the .git folder where tracking happens, changes are stored using linked lists!

---

Step 2 - Staging Files

git add <filename>
git add .

“git add” command informs git to hold files in temporary holding area called staging area. Staging does not create history yet!

---

Step 3 - Committing Files

git commit -m <Message>

When we commit using easy to understand message, we confirm git to take snapshot and store it inside .git.

---

Inside .git folder

The .git folder is Git’s brain and memory. Upon deleting it, all history wipes off and project becomes a normal folder.

Components of .git folder

📁 .git/objects/

This is where all the data is stored. Git doesn’t store files by name, instead it stores content identified by hash

📁 .git/refs/

As name suggests, it stores pointers to commits.

📄 .git/HEAD

It points to the current branch

📁 .git/index

This is the staging area (binary file).

It stores:

• Which files are staged

• Their hashes

📌 This is why git add is fast.

---

📁 .git/logs/

It keeps a history of reference movements.

Used for:

• git reflog

• Recovering lost commits

---

📄 .git/config

Repository-specific settings can be found in this folder.

3. Git Objects - blobs, trees & commits

1️⃣ Blob (Binary Large Object)

A blob stores the content of a file, and nothing else.

Git:

• Calculates a hash of this content

• Stores it as a blob object

If two files have identical content:

• Git stores only one blob

• Both files point to the same blob

What a Blob does NOT store

❌ File name

❌ File path

❌ File permissions (mostly)

Why hashing??

Git assigns a unique fingerprint called hash based on contents of a file for every file staged. It assigns hashes because

• Unique Identity for File Content

  When Git hashes a blob, the hash becomes the ID of that content. This means git identifies files by what’s inside, not by name

  📌 Same content → same hash

  📌 Different content → different hash If another file has exactly the same content, Git does not store it again.

• Automatic Deduplication (Huge Space Saving)

  Because content is hashed:

  • Duplicate content is stored only once

  • Multiple files can point to the same blob

Without hashing:

• Git would store copies

• Repo size grows fast

• Immutability (History Can’t Be Tampered With)

  Once a blob is stored:

  • Its content cannot change

  • Changing content = new hash = new blob

So:

• Old commits stay safe forever

• History is trustworthy

2️⃣ Tree (Directory Object)

A tree represents a directory (folder) in Git.

What a Tree contains

• File names

• Subdirectory names

• Pointers to blobs or other trees

• File permissions

Why trees matter

• Preserve directory hierarchy

• Map filenames to file content

• Allow Git to reconstruct the project

📁 Tree are like table of contents, pointing to actual pages (blobs).

3️⃣ Commit (Snapshot Object)

A commit represents a snapshot of the entire project at a specific time.

What a Commit contains

• Hash of the root tree

• Hash of parent commit(s)

• Author and committer info

• Timestamp

• Commit message

📌 Commit does NOT store file content directly.

In short, Blobs store content, trees store structure(including reference to blobs), and commits store snapshots and history.

It is this robust internal working that makes git so powerful and one of the most used version control system among developers.