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

1. How Git Works Internally ?

1. First of all what exactly is .git folder

   The .git folder is the repository itself.
   Your project files are just a working copy.
   The real Git data—history, commits, branches, everything—lives inside .git.

   If you delete the .git folder:

   • Your code remains

   • Git forgets everything

2. Why Git exists ?

   Because Git needs a place to store:

   • Project snapshots

   • Object data

   • Branch references

   • Metadata

2.Understanding the .git Folder

Now, we are going to explore contents of git folder

1. .git/head

   The HEAD file is a straightforward text file pointing to the current branch reference. It tracks which branch you're currently on.

2. .git/config

   Contains repository-specific configuration settings (like remotes, user info, aliases), separate from global Git config.

3. .git/objects/

   The heart of Git’s content storage. Git stores everything—files, directories, commits—as objects.

4. .git/ref/

   The .git/refs folder contains references (or "refs") that point to specific commits in your Git repository. These include branches, tags, and the HEAD pointer, all stored as plain text files.

5. .git/logs

   The .git/logs folder stores recent updates to references (try git reflog command after reading this section to have more understanding), which are histories of how Git references (like branches and HEAD) have changed over time.

6. .git/info

   Houses the exclude file, which can be used to ignore files locally, supplementing .gitignore.

7. .git/index

   Also called the staging area. Keeps track of changes staged for the next commit. It is a buffer between:

   • Your working directory

   • Your commit history

3.Git Objects: Blob, Tree, Commit

1. Blob — The Content

   A blob stores file content only.

   • No filename

   • No directory

   • Just raw data

If two files have the same content, Git stores one blob.

2. Tree — The Structure

   A tree represents a directory.

   • Maps filenames → blobs

   • Can point to other trees

   • Stores file permissions

Trees do not store file content. They only point to blobs.

3. Commit — The Snapshot

   A commit ties everything together.
   It stores:

   • A reference to a tree (project state)

   • A reference to parent commit(s)

   • Author, timestamp, message

A commit does not store files.
It stores references to them.

4.How Git Tracks Changes

This is where many beginners get confused. Git does not store line-by-line changes internally.
It stores snapshots of file states.

When you modify a file:

• Git does nothing immediately

• No tracking happens yet

Git only records changes when you:

• Stage (git add)

• Commit (git commit)

If a file hasn’t changed:

• Git reuses the old blob

• No duplication

• No extra storage cost

This is why Git is fast and efficient—even for large projects.

What Happens During git add

When you run git add:

• Git reads the file content

• Creates a blob object

• Hashes the content

• Stores it in .git/objects if it doesn't already exist (based on hash)

• Updates the index to point to that blob

What Happens During git commit

When you run git commit:

• Git reads the staging area

• Builds a tree object

• Creates a commit object pointing to the tree

• Links it to the parent commit

• Moves the branch pointer forward

Nothing is overwritten, nothing is deleted, unless you rewrite it.

Hashes: Git’s Superpower

This gives Git:

• Data integrity

• No duplication

• Tamper detection

If content changes:

• Hash changes

• Object identity changes

• History breaks visibly

This creates a chain of trust:

• Blob hash affects tree

• Tree hash affects commit

• Commit hash affects history

That’s why Git repositories are reliable at massive scale.