Today , I am learning Git and instead of memorizing the commands, suddenly my minds strikes and curious to know “ How Git internally works? “ When i researched on this i came to know that there is a folder named .git is not seen directly in the folder because it is hidden. It is hidden because it stores some sensitive information about code like what and why the user changed the code. So after knowing this i feel more curious about How git works and the Role of the .git folder.

Now let’s move towards our today’s Topic “ Inside Git : How it works and the Role of the .git folder “.

Understanding the .git folder :-

This folder is created when we initialise the git in our folder. But we can’t see it in the .git folder in our main folder because it is hidden .

We know the .git folder is the core of our repository it contains the metadata and the objects database for project’s version control history . It keep tracks changes . It is a hidden directory to prevent accidental modification or deletion, which would result in the loss of your project's entire history.

You can check .git folder by entring this command in powershell ls -Force

Key components of the .git folder :-

These are the following files or directories which are in the .git folder :-

Now let’s lear about them one by one :-

1. objects/ : This is Git’s object database , where all our projets’s content is stored . It contains :-

   • Blobs : The actual file contents.

   • Trees : Representation of directories and file names

   • Commits : Pointers to a specific tree (snapshot ) and its parent commits , forming the project history.

   • These objects are stored in a compressed format and referred to by thier unique SHA-1 hash values.

2. refs/ : This directory stores references (pointers) to commit objects , which help manage branches and tags.

   • heads/ : Contains pointers to the latest commit on each local branch.

   • remotes/ : Contains pointers to the last - fetched state of remote branches (e.g from Github)

   • tags/ : Contains pointers to specific commits that have been tagged.

3. HEAD : This file is a pointer that indicates which branch or commit yo are currently working on in our working directory.

4. index : This binary file serves as the staging area (or index) , acting as an intermediary between your working directory and the repository. It tracks modification and prepares them for the next commit.

5. config : This file contains repository - specific configuarations , such as the URL of the remote repository (e g on GitHub) , user information , and branch tracking settings.

6. hooks/ : This directory contains customizable sripts that GIt runs automatically at certain points in the version control workflow, such as before a commit (pre- commit ) or after a push ( post-recieve ).

7. logs/ : This folder maintains logs of changes made to branches and other references , including the reflogs , which sere as a safety net to recover lost commits

Git objects : Blob , Tree ,Commit :-

Git stores all of its data as aseries of immutable objects that link together to form a complete history of you project. The three main types of objects are blobs , trees , andcommits. Each object is identifies by a unique SHA-1 hash of its content.

Blob (Binary Large Object ) :-

A blob object stores the raw contents of a single file.

• Content: Just the file's data; it contains no metadata like the filename, creation date, or permissions.

• Purpose: To efficiently store file content. If two files in the repository (even in different commits or branches) have the same content, they will point to the same, single blob object, saving space through deduplication.

Tree :-

A tree object represents a directory or sub-directory within the project's file structure. It essentially acts as a directory listing, mapping names and permissions to other objects.

• Content: A list of entries, each containing:

  • File mode (permissions like 100644 for a normal file)

  • Object type (either blob or tree)

  • The SHA-1 hash of the referenced object

  • The filename or directory name

• Purpose: To organize blobs into a hierarchical file structure. A tree can reference both blobs (files) and other trees (subdirectories), creating a complete snapshot of the project's structure.

Commit :-

A commit object represents a single, complete snapshot of your project at a specific point in time, along with associated metadata.

• Content:

  • A pointer (SHA-1 hash) to the root tree of the entire project for that snapshot.

  • Pointers (SHA-1 hashes) to its parent commit(s), which links the history together.

  • Author and committer information (name, email, and date).

  • A commit message describing the changes.

• Purpose: To link the project's state (the tree) to its history and provide context for the changes. The chain of parent pointers forms a directed acyclic graph (DAG), which is the foundation of Git's version control capabilities.

How git Track Changes :-

Git track changes by using a content - addressable filesystem and a three - state model (working directory , staging area , and local repository) , primarily relying on unique SHA-1 hashes to identify and store file contents.

• Content Addressing (SHA-1 Hashes): Git doesn't track files by name and store a list of differences (deltas) for each change; instead, it tracks the entire content of files. When a file is added or changed, Git calculates a unique 40-character SHA-1 hash of its contents. This hash acts as a unique identifier and is used to store the content as a "blob" object in a hidden .git/objects directory.

• Snapshots, not Diffs: A "commit" in Git is a complete snapshot of your project at a specific point in time, not just the changes since the last commit. This snapshot (a "commit object") contains metadata (author, committer, message, timestamp) and a reference to a "tree object". The tree object maps filenames and directory structures to their corresponding content "blob" hashes.

• Efficiency: While Git logically stores full snapshots, it is highly efficient. If a file's content hasn't changed between commits, Git simply reuses the reference to the existing blob object, storing the content only once. Space-saving optimizations, such as delta compression, are applied periodically during garbage collection (git gc) to further reduce the repository's size.

• The Index (Staging Area): A key component is the "index" or "staging area".

  • To quickly detect if a file has changed in the working directory, Git initially checks file metadata like size and modification time against the data cached in the index.

  • Running git add calculates the hash of a modified file and places the new blob object into the database, updating the index with this new hash.

  • Running git commit then creates a permanent commit based on exactly what is in the staging area at that moment.

Conclusion :-

Understanding how Git works internally makes Git feel simple and logical, not confusing.
Instead of just memorizing commands, we learned what actually happens behind the scenes.

We saw that the .git folder is the heart of a Git repository. It stores everything Git needs—file content, project structure, commit history, and metadata. Git does not track files by name or line-by-line differences. Instead, it tracks file content using SHA-1 hashes and saves the project as snapshots using blobs, trees, and commits.

We also understood the importance of the three-state model—working directory, staging area, and local repository—which gives us full control over what changes go into each commit.

Once you understand these internal concepts, Git commands start making sense automatically.
You no longer use Git blindly—you use it with confidence and clarity.

Don’t just learn Git commands.
Understand Git—and it will stay with you forever.