Inside Git: How It Works and the Role of the .git Folder

Introduction

As a web development student, I used Git for a while like a set of commands I had to remember git add, git commit, and that is it. But when I started preparing for real projects and evaluations, I realised it is more useful to understand what Git is doing internally. This blog is my learner style explanation of how Git works under the hood, what the. git folder contains, and how Git tracks changes using objects and hashes.

How Git Works Internally

Git is a version control system, but internally it behaves like a content storage system. Instead of only saving “differences,” Git stores important snapshots in a structured way. The key idea I learned is:

• Git stores data in a local database inside the repository

• It builds a history using objects (blob, tree, commit)

• It uses hashes to uniquely identify and protect data integrity

This is why Git can reliably tell what changed, when it changed, and what the project looked like at any point.

Understanding the .git Folder

When we run git init, Git creates a hidden folder named .git. This folder is the “control center” of the repository because it stores everything Git needs to manage version history.

Important learner point:

• My project files (HTML/CSS/JS) are in the working folder

• Git’s tracking and history are maintained inside .git

• So, the .git folder exists because Git needs a dedicated place to store:

  a. object data (snapshots) b. references to commits and branches c. eta data required to track and restore history

Files:

.git/HEAD

.git/config

.git/description

.git/index

.git/packed-refs

Folders:

.git/hooks/

.git/info/

.git/objects/

.git/objects/info/

.git/objects/pack/

.git/refs/

.git/refs/heads/ .git/refs/tags/ .git/refs/remotes/

.git/logs/

.git/logs/HEAD (file) .git/logs/refs/ (folder)

.git/logs/refs/heads/ .git/logs/refs/remotes/ .git/logs/refs/tags/

Git Objects: Blob, Tree, Commit

Understanding Git objects helped me stop treating Git like magic. Git stores the repository as connected objects:

1. Blob (File Content): blob represents the actual content of a file. It does not store the filename only the content. So, if two files have the same content, Git can reuse the same blob.

2. Tree (Folder Structure): A tree represents a directory structure. It connects: filenames, blobs (file contents) and other trees (subfolders)

3. Commit (Snapshot + Message + Parent Link): A commit is like a saved checkpoint. It points to → a. A tree (project structure at that moment) b. A parent commit (previous checkpoint) c. A message and metadata

How Git Tracks Changes

Git tracks changes by comparing file content and storing new objects when content changes. The clean mental model for me is:

• If file content changes → Git stores a new blob

• If structure changes → Git stores a new tree

• If we “save” a snapshot → Git creates a new commit

This means Git history is not based on random copies like “final_v2,” but on structured checkpoints that point to objects.

I. What happens internally during git add: When I run git add, Git prepares the selected changes to be committed. Internally, it means Git is collecting and preparing updated content information so the next commit knows what to include.

II. What happens internally during git commit: When I run git commit, Git creates a new commit object that points to the updated tree and links it to the previous commit, forming a timeline.

III. How Git Uses Hashes to Ensure Integrity: One important reason Git is trusted is that it uses hashes. Every object (blob/tree/commit) has a unique hash based on its content. This gives two benefits à a. Uniqueness: Different content → different hash b. Integrity: If content is altered, the hash changes, so Git can detect inconsistency

This is how Git ensures the repository history is reliable and not easily corrupted without detection.

Conclusion

Understanding Git internally helped me build confidence: Git is not just commands—it is a structured system that stores project history using objects (blob, tree, commit) and secures it using hashes. The .git folder exists to store this internal database and tracking information. With this mental model, Git feels more logical, and I can use it with clarity instead of memorizing steps.