What is Git?

Git is a distributed version control system that tracks changes in your code. Think of it as a time machine for your projects—you can save snapshots of your work, experiment without fear, and collaborate with others without chaos.

Created by Linus Torvalds in 2005, Git has become the backbone of modern software development.

Why Developers Love Git

• Track every change: See who changed what, when, and why

• Experiment safely: Try new features without breaking your working code

• Collaborate easily: Multiple developers can work on the same project simultaneously

• Rewind time: Messed up? Just roll back to a previous version

• Work offline: Git works locally, no internet required

Core Concepts You Need to Know

Repository (Repo)

A folder that Git is tracking. It contains all your project files plus a hidden .git folder where Git stores its magic.

Commit

A snapshot of your project at a specific point in time. Think of it as a save point in a video game.

Branch

A separate line of development. The default branch is usually called main or master. Branches let you work on features without affecting the main codebase.

HEAD

A pointer that tells Git which commit you're currently looking at. It usually points to the latest commit on your current branch.

Staging Area

A middle ground between your working files and the repository. You choose which changes to include in your next commit.

The Git Workflow Visualized

Working Directory → Staging Area → Repository
    (edit files)   →  (git add)   → (git commit)

Essential Git Commands

Let's walk through a real workflow:

1. Initialize a Repository

git init

Transforms your current folder into a Git repository.

2. Check Status

git status

Shows which files have changed and what's staged for commit. This is your best friend—use it often!

3. Stage Files

git add filename.txt        # Stage a specific file
git add .                   # Stage all changes

Moves changes to the staging area, preparing them for a commit.

4. Commit Changes

git commit -m "Add login feature"

Creates a snapshot with a descriptive message. Write clear messages—your future self will thank you!

5. View History

git log                     # Full history
git log --oneline           # Compact view

Shows your commit history so you can see what happened when.

6. Create and Switch Branches

git branch feature-navbar   # Create a new branch
git checkout feature-navbar # Switch to it
# Or do both at once:
git checkout -b feature-navbar

7. Merge Branches

git checkout main
git merge feature-navbar

Brings changes from one branch into another.

8. Clone a Repository

git clone https://github.com/username/repo.git

Downloads a complete copy of a remote repository to your machine.

A Beginner's Workflow Example

Let's say you're building a website:

# Start tracking your project
git init

# Check what's happening
git status

# Create your first HTML file
echo "<h1>Hello Git!</h1>" > index.html

# Stage it
git add index.html

# Commit it
git commit -m "Create initial homepage"

# Make changes
echo "<p>Welcome to my site</p>" >> index.html

# See what changed
git status

# Stage and commit again
git add index.html
git commit -m "Add welcome message"

# View your history
git log --oneline

Quick Reference Cheatsheet

Commit History Flow

Each letter represents a commit. You can branch off, work independently, then merge back.

Pro Tips for Beginners

1. Commit often: Small, focused commits are better than giant ones

2. Write clear messages: "Fix bug" is bad, "Fix login button alignment" is good

3. Use branches: Keep your main branch stable

4. Check status frequently: Before and after every operation

5. Don't panic: Git is very forgiving—most mistakes can be undone

What's Next?

You've now got the foundation! From here, explore:

• Remote repositories (GitHub, GitLab)

• Collaboration workflows (pull requests)

• Advanced commands (rebase, stash, cherry-pick)

But for now, start practicing these basics. Create a test project, make some commits, create branches, and experiment. The more you use Git, the more natural it becomes.

Happy coding!

The .git Folder: Git's Brain

When you run git init, Git creates a .git folder in your project. This folder is Git's entire brain - it contains everything Git knows about your project's history.

Here's what's inside:

.git/
├── HEAD              # Points to the current branch
├── config            # Repository-specific configuration
├── description       # Repository description (used by GitWeb)
├── hooks/            # Client and server-side hook scripts
├── info/             # Global exclude file for ignored patterns
├── objects/          # Git's object database (the most important!)
│   ├── pack/         # Compressed object storage
│   └── [hash dirs]   # Individual object files
├── refs/             # References to commits (branches, tags)
│   ├── heads/        # Local branches
│   ├── remotes/      # Remote branches
│   └── tags/         # Tags
└── index             # The staging area (more on this later)

The key insight: Your working directory is just a checkout. The real project history lives in .git/objects.

Git Objects: The Building Blocks

Git stores everything as objects, and there are three main types:

1. Blob (Binary Large Object)

• Stores file content

• Just the content, no filename or metadata

• Identified by a SHA-1 hash of the content

2. Tree

• Like a directory listing

• Maps filenames to blobs or other trees

• Represents the structure of your project at a point in time

3. Commit

• Points to a tree (snapshot of your project)

• Contains metadata: author, message, timestamp

• Points to parent commit(s), forming the history chain

What Happens During git add?

When you run git add file.txt:

1. Git calculates a hash of the file content (SHA-1)

2. Compresses the content and stores it as a blob in .git/objects/

3. Updates the index (staging area) to point to this blob

Important: The file content is already saved in Git's database, even before you commit!

What Happens During git commit?

When you run git commit -m "message":

1. Git creates a tree object representing your staged files

2. Git creates a commit object that:

   • Points to this tree

   • Contains your commit message

   • Points to the parent commit (previous commit)

   • Stores author info and timestamp

3. Updates the branch pointer (e.g., refs/heads/main) to point to this new commit

How Git Uses Hashes

Every Git object has a unique SHA-1 hash (40 characters, like a3b2c1d4e5...). This hash is:

• Content-based: Same content = same hash

• Used as filename: Objects are stored as .git/objects/ab/c123...

• A guarantee of integrity: If content changes, hash changes

This is why Git can detect if files have changed - it just compares hashes!

The Mental Model

Think of Git like this:

• Blobs = Pages of a book (content only)

• Trees = Table of contents (structure)

• Commits = Bookmarks with notes (snapshots + history)

• Branches = Sticky notes pointing to bookmarks

When you make changes:

1. git add → Save pages (blobs) and update the draft table of contents (index)

2. git commit → Create a new bookmark (commit) with a finalized table of contents (tree)

Key Takeaways

1. The .git folder is Git's database - everything is stored there

2. Git stores snapshots (commits), not differences

3. Objects (blob, tree, commit) are the core data structures

4. Hashes ensure data integrity and enable Git's superpowers

5. Branches are just lightweight pointers to commits

Understanding these internals helps you reason about Git commands instead of memorizing them. Next time you run git add, you'll know you're creating a blob and updating the index. When you git commit, you're creating a tree and a commit object that preserves a snapshot forever.

Happy versioning!

Now imagine doing this without Google Docs. That's what software development was like before version control systems.

The Pendrive Days: How Developers Used to Share Code

Before tools like Git existed, developers had to get creative (and frustrated) with how they shared code. Let me paint you a picture of what this looked like:

The Pendrive Shuffle

Meet Rahul, Paritosh, and Daanish - three developers working on a website for their company.

Monday Morning:

• Rahul writes some code for the login page on his computer

• He copies the entire project folder to a pendrive

• Walks to Paritosh’s desk and says, "Here's the latest code"

• Paritosh copies it to her computer

Monday Afternoon:

• Paritosh adds a signup page

• Meanwhile, Rahul fixes a bug in the login page (on his old version)

• Paritosh copies her version to the pendrive and gives it to Daanish

Tuesday:

• Daanish has both Rahul's and Paritosh's pendrives on his desk

• Which one has the latest code? Nobody knows!

• Rahul's bug fix? Gone. Overwritten by Paritosh's version.

Sound chaotic? It was.

The Email Chaos

Some teams tried using email instead:

Subject: Final Code - v1
Subject: Final Code - v2 (ACTUAL FINAL)
Subject: Final Code - v2.1 (fixed bug)
Subject: Final Code - v3 (With X feature)
Subject: Final Code - v4 (With minor last minute fixings)
Subject: FINAL_FINAL_Code

Your inbox became a graveyard of ZIP files. Good luck finding which one actually worked.

The Folder Madness

On developers' computers, you'd see folders like this:

project/
├── old/
├── backup/
├── backup_2/
├── backup_old/
├── final/
├── final_2/
├── final_final/
├── final_actually_final/
├── latest/
├── latest_new/
└── use_this_one/

Every developer had their own naming system. "Final" meant nothing. "Latest" was never actually the latest.

The Real Problems This Caused

Let's look at what went wrong with these methods:

Problem 1: The Overwrite Disaster

Scenario: Rahul spent 5 hours fixing a critical security bug. He saved it in the "final" folder. Paritosh didn't know about this fix. He copied her version (without the fix) over the "final" folder. Rahul's work? Vanished.

Result: The security bug went to production. The company got hacked. All because there was no way to merge their work properly.

Problem 2: Who Changed What?

The login page suddenly broke. It worked yesterday. Who changed it? Was it:

• Rahul?

• Paritosh?

• Daanish?

• That intern who left last month?

Nobody knew. There was no history. No record. Just a broken login page and three people blaming each other in a meeting.

Problem 3: Going Back in Time

Remember that feature you removed last week? The boss wants it back.

With folders and pendrives, you had to:

1. Search through 47 backup folders

2. Hope you didn't delete that version

3. Try to remember which folder had which features

4. Manually copy-paste code between files

More often, you'd just rebuild the feature from scratch because finding the old version was impossible.

Problem 4: Working Simultaneously

Two developers couldn't work on the same file at the same time. If Rahul was editing login.js, Paritosh had to wait. Or He could edit her copy, but then they'd have to manually merge their changes line by line.

This meant:

• Lots of waiting around

• Lots of "Are you done with that file?"

• Lots of conflicts when merging manually

Problem 5: No Code Review

How do you review someone's code when it arrives via pendrive?

You couldn't see:

• What exactly changed

• Why it changed

• When it changed

• What else changed at the same time

You had to open two folders side by side and manually compare files. For a large project, this could take hours.

Real-World Team Collaboration Nightmare

Let's follow a disaster in action:

The Team: 5 developers working on an e-commerce website

Week 1: Development

• Dev 1 creates the product catalog (saves to pendrive)

• Dev 2 creates the shopping cart (saves to another pendrive)

• Dev 3 fixes the homepage (emails ZIP file)

• Dev 4 adds payment system (saves to shared drive)

• Dev 5 improves the database (has it on their laptop)

Week 2 - Integration Day:

• Everyone brings their code together

• Dev 1's catalog doesn't work with Dev 4's payment system

• Dev 3's homepage breaks Dev 2's cart

• Dev 5's database changes require everyone to update their code

• Nobody knows which version is the "correct" base to start from

Result: 3 days wasted trying to manually merge everything. The launch date gets pushed by a week.

The Breaking Point

Eventually, software projects became too complex for pendrive juggling:

• Projects got bigger: 100 files became 10,000 files

• Teams got larger: 3 developers became 50 developers

• Speed mattered: Waiting for a pendrive was too slow

• Companies lost money: Every overwrite or lost feature cost real money

Developers realized: We can't work like this anymore.

Enter Version Control Systems

This is why version control systems like Git were created. They solve every problem we discussed:

Instead of pendrive shuffle:

• Everyone has the complete code history on their computer

• No physical device needed

• No walking to desks

Instead of folder madness:

• One folder, infinite versions

• Every change is tracked automatically

• You can jump to any point in history instantly

Instead of overwrites:

• Your changes can't accidentally delete someone else's work

• The system warns you about conflicts

• Changes are merged intelligently

Instead of "Who broke it?":

• Every change shows who made it, when, and why

• Complete history of every line of code

• Easy to find when bugs were introduced

Instead of manual merging:

• Multiple people can work on the same file

• The system merges changes automatically

• Conflicts are clearly highlighted

The Modern Way

Today, this is how it works:

1. Rahul writes login code and "commits" it with a message: "Added login feature"

2. Paritosh "pulls" Rahul's changes to her computer instantly

3. Paritosh adds signup and commits: "Added signup page"

4. Rahul pulls Paritosh's changes

5. Both have the complete code with full history

6. If they edit the same line, the system alerts them to resolve it together

No pendrive. No email. No confusion.

The Bottom Line

Version control systems didn't just make development easier—they made modern software development possible.

Without version control:

• Google couldn't have thousands of engineers working on Chrome

• Facebook couldn't coordinate updates across teams

• Your favorite app couldn't fix bugs without breaking everything

The pendrive era taught us a valuable lesson: When humans try to track changes manually, chaos wins.

Version control systems do what computers do best—remember everything perfectly, merge changes logically, and let humans focus on writing great code instead of managing files.

Visual Comparison

Before Version Control (The Pendrive Era)

Developer A's Computer          Pendrive          Developer B's Computer
     [Code v1]         --->    [Code v1]    --->      [Code v1]
          |                                                |
    [Makes changes]                                  [Makes changes]
          |                                                |
     [Code v2a]                                       [Code v2b]
          |                                                |
          ?????????  <--- Who has the latest? --->   ?????????

Result: Lost changes, confusion, conflicts

After Version Control (Modern Way)

   Developer A              Central Repository              Developer B
       |                           |                              |
       |--- Push changes --------> |                              |
       |                           |                              |
       |                           | ------- Pull changes ------->|
       |                           |                              |
       |<------ Pull updates ------|                              |
       |                           |                              |

Result: Everyone in sync, complete history, no lost work

The moral of the story?

We needed version control because pendrive-driven development was like trying to build a skyscraper using sticky notes. It might work for a tiny project, but anything serious needs a proper system.

And that's exactly what version control gave us - a professional, reliable way to build software together.