So, in my last few posts, I talked about how to use Git (you know, the usual add, commit, push dance). But honestly? I felt like I was just memorising magic spells without knowing how the magic actually worked. It felt like if I made one wrong move, the whole thing would explode.

So, I decided to peek under the hood and look into the .git folder. It’s actually kind of mind-blowing how simple (and also weird) it is. Here is my attempt to explain the "internals" of Git without sounding like a textbook.

1. That Mysterious .git Folder

If you go to your project folder and show hidden files, you’ll see a folder named .git.

Do not delete this. I learned the hard way that if you delete this folder, your project is no longer a "Git repo." It just becomes a regular folder, and your entire history—every save point you ever made—is gone forever.

Think of the .git folder as the brain of your project. It stores every version of every file you’ve ever committed. If your project files are the "body," the .git folder is the "memory."

2. The Big Three: Blobs, Trees, and Commits

Git doesn't see "files" and "folders" the way we do. It sees Objects. Everything in Git is stored as an object with a weird name like e69de29bb2d1d643....

This name is a Hash (specifically SHA-1). It’s basically a unique fingerprint. If you change even one comma in your code, the fingerprint changes completely. This is how Git knows for sure that nothing has been corrupted or lost.

There are three main types of objects you need to know:

• Blobs (Binary Large Objects): This is just a fancy word for your file content. Git doesn't care about the filename here; it only cares about what’s inside the file. If you have two different files with the exact same text, Git only stores one blob! Efficiency, right?

• Trees: Think of these as Folders. A Tree object lists the blobs (files) and other trees (sub-folders) inside it. It links the filenames to the blobs.

• Commits: This is the "snapshot." A commit object points to a specific Tree (representing the project state) and contains the author, the date, and the parent commit (the one that came before it).

3. What happens when you git add and git commit?

This was the "Aha!" moment for me. Here’s the internal flow:

Step 1: git add

When you run git add, Git takes the content of your file and creates a Blob. It then puts that blob into the .git/objects folder. It also updates a file called the Index (or Staging Area), which is basically a list saying, "Hey, next time we commit, include this blob."

Step 2: git commit

This is where the magic happens. Git:

1. Creates a Tree object to represent the structure of your project right now.

2. Creates a Commit object that points to that Tree.

3. Moves the HEAD (the "You Are Here" pointer) to this new commit.

4. Why does this matter?

Before I looked into this, I thought Git was saving "diffs"—like, it just saved the lines I changed. But that’s not true! Git actually takes a full snapshot of your files every time. If a file hasn't changed, it just points to the old blob from the previous version to save space.

The Mental Model:

Instead of thinking of Git as a list of changes, think of it as a Map of Snapshots. Because every commit has a unique hash based on its content, it's basically impossible to lose data or have a "silent error."

It’s like Lego. Every commit is a finished structure. If you want to change it, you don't just swap a brick; you build a new version of the structure using some of the old pieces and some new ones, then take a photo of it.

Summary for my fellow students:

• The .git folder is the database.

• Hashes are the fingerprints that keep everything safe.

• Blobs = Content, Trees = Folders, Commits = Snapshots.

Honestly, knowing this makes the error messages in Git make way more sense. You stop seeing it as a buggy tool and start seeing it as a very organised, very fast librarian.

So, I’ve been diving into web development lately, and honestly, the hardest part isn't the code itself—it’s keeping track of my own files. If you’re like me, your desktop probably looks like a graveyard of folders named project, project_final, project_ACTUALLY_FINAL, and my personal favorite, project_REAL_FINAL_v2_USE_THIS_ONE.

I finally realized there’s a better way to live, and it’s called Version Control. I wanted to write a quick post about why this exists and why the "old school" way of doing things is basically a nightmare.

The "Before Times": The Pendrive Struggle

Before things like Git existed, developers had to get... creative. Imagine you’re working on a group project. Since you can't both edit the same file at the exact same time online, you’d probably do one of these:

• The Pendrive Shuffle: You finish your part, save it on a USB stick, and literally hand it to your friend.

• The Email Chain: You email script_v1.py to your partner. They change two lines, rename it script_v1_fixed.py, and email it back.

• The Shared Folder: You both have access to a Google Drive or Dropbox, and you just pray you don't both hit "Save" at the same time.

Why the Pendrive Method is a Disaster

It sounds "fine" for a small homework assignment, but in real software development? It’s a total train wreck. Here’s why:

1. The "Who Broke It?" Mystery

Without version control, you have no history. If the code worked on Tuesday but stopped working on Wednesday, you have to manually remember every single line you changed. There’s no "Undo" button for your whole project.

2. The Overwriting War

This is the worst part. Imagine Developer A is fixing a bug in the header, and Developer B is adding a button to the same header.

• Developer A saves their work.

• Developer B saves their work five minutes later.

• Poof. Developer A’s bug fix is gone because Developer B’s file just overwrote the whole thing.

3. Zero Collaboration History

When you're looking at a piece of code six months later and it makes no sense, you want to know why it was written that way. With the pendrive/email method, that info is lost forever. You don't know who wrote it or what they were thinking.

The Problem of "The Lost Version"

We’ve all been there. You try a new "cool" feature, realize it’s garbage, and try to go back to the version that worked. But wait... did you save the working version as final or final_v2? You open both, and they both look broken.

Without a system, your project timeline isn't a straight line; it's a messy web of files where things constantly get deleted or lost in the void.

The Transition: Why We Need Version Control

Eventually, developers realised that humans are messy and pendrives get lost. We needed a "System of Record."

Version Control Systems (like Git) act like a high-tech security camera for your code. It records every single change, who made it, and why. It allows two people to work on the exact same line of code and then "merges" those changes together intelligently.

It basically takes the stress out of "breaking things." If you mess up, you just jump back in time to when it worked. No pendrives required.

I’m still learning the commands, but honestly, just knowing I don't have to name my files v1, v2, v3 anymore makes my brain feel so much lighter.

What about you? What's the most ridiculous "final_v7" filename you've ever used? Let me know!

Okay, raise your hand if you’ve ever been working on a school project or an essay and your folder looks like this:

• project.py

• project_v2.py

• project_FINAL.py

• project_ACTUALLY_FINAL_DONT_TOUCH.py

Yeah, me too. It’s a mess. And when you start getting into bigger coding projects, especially if you have to work with a partner in class, this method is basically a disaster waiting to happen. You overwrite each other's work, you forget what you changed yesterday, and you can't go back if you break something.

I’ve started learning programming more seriously, and everyone kept talking about "Git." At first, it just seemed like another confusing thing to learn on top of actual coding. I avoided it.

But I finally sat down to learn the basics, and honestly? It’s a lifesaver. It’s not as scary as it looks in the terminal. So, I wanted to write down what I’ve learned in plain English, student-to-student, while it's still fresh in my brain.

Here is my attempt at explaining Git without making it overly complicated.

What Actually is Git?

If you look up the definition, it says Git is a "distributed version control system."

Okay, cool fancy words. What does that mean?

Think of Git as a really advanced "Save" button, or better yet, a time machine for your project. It tracks every single change you make to your code.

If you are working on a feature and completely mess it up (which I do... often), you don't have to panic delete everything or try to remember what the code looked like an hour ago. You can just tell Git, "Hey, take me back to the version from this morning when everything worked."

The "distributed" part just means you don't need to be connected to a main server to use it. The whole history of your project lives right on your laptop.

Why Do We Need It?

Besides solving the final_v3.txt file name mess, here is why it’s actually useful:

1. Safety Net: As I mentioned, if you break your code, you can undo it easily. It gives you confidence to try weird experiments because you know you can always go back.

2. Working in Teams: This is huge. Git allows multiple people to work on the same files at the same time without overwriting each other's work. Git is smart enough to merge the changes together.

3. It’s what the pros use: Seriously, almost every software job out there requires you to know Git. Might as well learn it now.

The Basics and The Confusing Terms

Before we type commands, we need to understand the mental picture. This was the hardest part for me.

Git doesn't just snap its fingers and save your files. There is a process. Imagine moving boxes.

The 3 Stages Conceptual Diagram:

[Working Directory (Your messy room)] --> [Staging Area (Putting things in a box)] --> [Repository (Taping the box shut and labelling it)]

1. Working Directory: This is just the folder on your computer where you are currently typing code. The files are currently "messy" and unsaved in Git's eyes.

2. Staging Area: This is a virtual waiting room. You tell Git, "Okay, I like these specific files, I want to include them in my next snapshot." You "stage" them.

3. Repository (or the .git folder): This is where the permanent history lives. When you move things from the staging area to here, you take a snapshot that is saved forever.

Core Terms:

• Repo (Repository): Just the project folder that Git is managing.

• Commit: This is the most important word. A "commit" is a saved snapshot of your project at a specific point in time. It’s like a save point in a video game. Every time you finish a task, you should make a commit.

• Branch: Imagine alternate timelines in a sci-fi movie. The main timeline is usually called main or master. If you want to try a crazy experiment, you create a new "branch" (an alternate timeline). You can mess around there. If it works, you merge it back to the main timeline. If it fails, you delete the branch, and the main timeline never knew it happened.

• HEAD: A little pointer that just says, "You are currently looking at this commit right here."

Let’s Actually Do It (Common Commands)

Okay, open up your terminal (command prompt). Don't be scared of the black box. We are going to simulate a basic workflow.

1. Starting a project (git init)

Navigate to a folder where you want to start a project. To tell Git to start watching this folder, type:

git init

Student thought: It’ll say something like "Initialized empty Git repository". Now there is a hidden .git folder inside your project folder. Don't touch that folder. It's magic.

2. Checking what’s going on (git status)

I use this command constantly. It tells you what state your files are in.

Let's create a new file called hello.py and just put print("Hello World") in it.

Now go back to terminal and type:

git status

Git will tell you it sees an "Untracked file" in red text. It sees the file, but it's not watching it yet.

3. Moving to the waiting room (git add)

We need to move our file from the Working Directory to the Staging Area. We use git add.

git add hello.py

Quick tip: If you want to add EVERY file you changed, just type git add . (don't forget the dot).

If you type git status again now, you'll see the file name in green text. It’s ready to be committed.

4. Taking the snapshot (git commit)

This is the big moment. We are saving the state of the staging area permanently into the history.

You gotta add a message so your future self knows what you did.

git commit -m "Added my first hello world script"

The -m stands for message. Don't skip this! If you just type git commit, it opens up a weird text editor (usually Vim) that is impossible to exit if you don't know how. Stick to -m for now.

5. Seeing history (git log)

Want to prove you actually did something?

git log

This will show a list of all the commits you've made, who made them, when, and that little message you wrote. It’s your project's history book.

Wrap up

Okay, that's literally just the surface. I didn't even talk about GitHub (which is like putting your Git repository on the internet) or how to merge branches.

But honestly, if you can just get comfortable with git status, git add, and git commit, you are already doing way better than the final_v4.py method. It feels clunky at first, but after a few days, your fingers just kind of learn the muscle memory.

Give it a try on your next small homework assignment. Good luck!