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

How Git Works Internally

We often use commands like git add and git commit without thinking about what is happening behind the scenes. But to truly master Git, we need to understand its "brain." By opening up the hidden .git folder, we can move from memorizing commands to understanding the system.

Understanding the .git Folder

Every time we run git init, it creates a special .git folder in our project. By default, this file is not in your project folder.

• The Tracking File: If we want to track the project by Git, it creates this special hidden folder so it can tell you "you shouldn't change it" or "it will ruin your project".

• No Manual Work: We don't have to create a change.txt along with all our files to track everything manually; Git handles the difference between "old and new" internally.

• Integrity: All of our history is stored in this .git folder.

Git Objects: Blob, Tree, Commit

Git separates the address of a file from the actual "content".

• Blob: This is just the actual content of your file; Git focuses only on the data inside and ignores the filename to save it as a "Binary Large Object" in the objects folder.

• Tree: This acts like a digital map or folder that connects your filenames to the correct Blobs, keeping track of where each piece of content belongs in your project structure.

• Commit: This is the final snapshot or "Save Point" that points to a Tree and includes the "address" (Hash), the author's name, the date, and your commit message.

• Hashes: Every commit has an ID or "Hash". Git is so smart that even starting with a few characters of the ID will work to find the commit.

How Git Tracks Changes

Git is designed to track the changes or differences between several commits.

• git add .: If we have 200 files, it's too hard to add them one by one. This command prepares all files at once, moving them into the Staging Area.

• git status: This tells us what we've done (modifications, etc.) by tracking the work.

• git diff: This shows the actual modification. Like for tracking changes between two commits first write git diff, then the Hash ID of the first commint then the second commit Hash ID

• The Staging Area: To send only a particular file or changes to the staging area, we use git add <filename>.

Integrity: How Git Ensures Nothing is Lost

You might have noticed long strings of random letters and numbers like 4a2b3c.... These are called Hashes.

Every piece of data in Git is given a unique ID based on its content.

• If we change even a single comma in a file, the Hash changes completely.

• This is how Git ensures Integrity. We can’t change a file without Git noticing, because the the Hash won't match anymore.

The "Linked List" Mental Model

We can imagine Git's history as a Linked List.

• Each Node in the list is a commit.

• Each node stores its own address (hash) and the address of the commit that came before it.

• Branching: When we branch, we are essentially starting a new path from one of these nodes.

Fixing Mistakes: Reset vs. Revert

Git Revert is usually better than Git Reset.

• git revert: This creates a new commit that is the complement (the opposite) of the bugged commit. It’s safe because it doesn't delete history.

• git reset --hard: This is a dangerous command. It moves the HEAD back

  and deletes the work in between. Once deleted, you can't easily go forward again.

• git reset (Safer version): Using a basic reset is safer than --hard because it resets the HEAD but keeps your work in the staging area instead of deleting it.

How Git "Finds" Your Place

If Git needs to know where you are, it follows a simple trail:

1. It goes into .git/HEAD to see your current branch (e.g., ref: refs/heads/main).

2. It then looks at .git/refs/heads/main to find the Address (Hash) of the latest commit.

3. Finally, it looks in the objects folder to find the Content belonging to that address.

Thanks for read! you can watch this short video for Working of Git