When you type google.com into your browser, a surprising amount of distributed system machinery spins up behind the scenes.
At the heart of it all is DNS — the Domain Name System.

This article breaks DNS down layer by layer using the dig command, so you can see how name resolution actually works instead of memorizing theory.

DNS: The Internet’s Phonebook ☎️

Humans remember names.
Machines route traffic using IP addresses.

DNS exists to translate human-friendly domain names like:

google.com

into machine-friendly IP addresses like:

142.250.190.14

Without DNS, we’d be browsing the internet by typing numbers—clearly not ideal.

Key idea:

DNS is a globally distributed, hierarchical database optimized for reads.

Introducing dig: Your DNS X-Ray Tool 🔍

dig (Domain Information Groper) is a command-line tool that lets you inspect DNS resolution at every layer.

You use dig when you want to:

• Debug DNS issues

• Understand name server delegation

• See authoritative vs recursive behavior

• Learn how browsers actually resolve domains

Basic syntax:

dig <name> <record-type>

DNS Resolution Happens in Layers

DNS resolution is not a single lookup.
It’s a chain of delegations:

4

Root servers (.)
   ↓
TLD servers (.com, .org, .net)
   ↓
Authoritative servers (google.com)

Let’s walk this hierarchy using dig.

dig . NS — Root Name Servers 🌍

dig . NS

This asks:

“Who is authoritative for the root zone?”

What you’ll see

• Servers like a.root-servers.net

• Managed by organizations like Verisign, ICANN, etc.

Key points:

• There are 13 logical root servers (A–M)

• Each is anycasted globally (hundreds of physical instances)

• Root servers do not know IPs for google.com

• They only know where .com lives

Think of them as:

“I don’t know the answer, but I know who to ask next.”

dig com NS — TLD Name Servers 📛

dig com NS

This queries the Top-Level Domain (TLD) servers for .com.

What this tells us

• .com is managed by Verisign

• These servers know:

  • Which name servers are authoritative for google.com

• They still don’t know google.com’s IP

TLD servers act as:

A directory of domains registered under .com

dig google.com NS — Authoritative Name Servers 🏛️

dig google.com NS

Now we’re asking:

“Who is authoritative for google.com?”

Output highlights

• Name servers like:

    ns1.google.com
    ns2.google.com
    ns3.google.com
    ns4.google.com
  

These servers:

• Are controlled by Google

• Hold the actual DNS records

• Provide final answers (A, AAAA, MX, TXT, etc.)

This is where truth lives in DNS.

dig google.com — Full DNS Resolution 🔄

dig google.com

This returns:

• A records (IPv4)

• Possibly AAAA records (IPv6)

• TTL values

• Which server answered the query

But here’s the important part:

Your system did not query root → TLD → authoritative directly.

Instead, this was handled by a recursive resolver.

Recursive Resolvers: The Hidden Middleman 🧠

Your laptop/browser typically asks:

• ISP DNS

• Google DNS (8.8.8.8)

• Cloudflare (1.1.1.1)

4

What the recursive resolver does

1. Ask root servers for .com

2. Ask .com servers for google.com

3. Ask Google’s authoritative servers for IP

4. Cache the result

5. Return the IP to your browser

All in milliseconds.

Mapping dig Commands to DNS Stages

4

This mapping is gold for system design interviews.

Why NS Records Matter in System Design

NS records:

• Enable horizontal scaling of DNS

• Allow delegation without central coordination

• Prevent single points of failure

• Make DNS one of the most resilient systems ever built

Design insight:

DNS works because no server needs to know everything.

Connecting DNS to Real Browser Requests 🌐

When you type https://google.com:

1. DNS resolves google.com → IP

2. TCP connection is established

3. TLS handshake happens

4. HTTP request is sent

If DNS fails:

• Nothing else even starts

That’s why DNS latency and availability are critical at scale.

Final Takeaways

• DNS is a hierarchical, distributed database

• dig lets you observe DNS like a systems engineer

• Root → TLD → Authoritative is the backbone of resolution

• Recursive resolvers hide complexity but rely on this hierarchy

• Understanding DNS deeply pays off in backend, infra, and SRE roles

If you’ve ever seen folders named final, final_v2, or latest_final_REAL, then you already understand why version control exists.

Let’s go back in time.

Life Before Version Control Systems

Imagine a team of developers working on the same project…
without Git, without cloud repos, without history tracking.

How did they share code?

• Pendrives (USB drives)

• Email attachments

• Shared folders

• Manual backups

It worked — until it didn’t.

The Pendrive Analogy 🧠

Think of a pendrive as the “source of truth”.

Typical Workflow Back Then

1. Developer A copies the project to a pendrive

2. Makes changes

3. Hands the pendrive to Developer B

4. Developer B overwrites their local copy

5. Someone forgets to copy a file

6. Chaos begins 😅

There was no system, just trust and hope.

The Famous Folder Names 😬

Developers tried to protect themselves by duplicating folders:

project/
├── final/
├── final_v2/
├── final_v2_updated/
├── final_latest/
├── final_latest_REAL/

Each folder was a manual version of the project.

Problems?

• No idea what actually changed

• No clarity on which version is correct

• Huge waste of time and storage

Problems Faced Before Version Control

Let’s break down the real issues.

1. Overwriting Code

Two developers edited the same file.

• Developer A updates login.js

• Developer B updates login.js

• One copy overwrites the other

💥 Someone’s work is gone forever.

2. No History of Changes

Questions no one could answer:

• Who changed this?

• When did it break?

• What was the working version yesterday?

There was no audit trail.

3. Lost Changes

Files got lost due to:

• Accidental deletes

• System crashes

• Wrong folder copied

• Pendrive corruption

Once lost → unrecoverable.

4. No Collaboration Model

Teams couldn’t:

• Work in parallel

• Experiment safely

• Review each other’s changes

Everything had to be sequential — one person at a time.

5. No Rollback

If a new change broke the app:

• There was no “go back”

• Only guesswork and panic

🚫 No undo button.

Visualizing the Problem: Timeline Chaos

Versions jumped randomly:

• v1 → v3 → v2 → broken

• No clean history

• No confidence

Why Version Control Became Necessary

As software grew:

• Teams became larger

• Codebases became complex

• Releases became frequent

Manual methods could not scale.

Developers needed a system that could:

• Track every change

• Preserve history

• Support collaboration

• Prevent overwrites

• Allow rollback

That system is Version Control.

Version Control vs Pendrive Workflow

Pendrive Workflow ❌

• One copy at a time

• No history

• Manual backups

• High risk

Version Control Workflow ✅

• Everyone works independently

• Full change history

• Automatic backups

• Safe collaboration

How Version Control Solves These Problems

Version control systems:

• Track who changed what and when

• Prevent accidental overwrites

• Allow multiple developers to work in parallel

• Provide rollback to any previous state

• Maintain a clean project timeline

In short:

Version control replaces chaos with confidence.

Why Version Control Is Mandatory Today

Modern development depends on:

• Remote teams

• CI/CD pipelines

• Open-source collaboration

• Fast release cycles

Without version control:
🚫 None of this is possible.

That’s why learning Git isn’t optional — it’s foundational.

Final Thoughts

The pendrive era taught developers a hard lesson:
Manual versioning doesn’t work at scale.

Version control exists because:

• Humans make mistakes

• Teams need coordination

• Software must evolve safely

Once you understand this history, Git no longer feels like “just another tool” —
it feels like a solution to a real problem.

In this article, we’ll explore:

• What the .git folder really is

• How Git stores data internally

• Git objects: Blob, Tree, Commit

• What actually happens during git add and git commit

• How Git uses hashes to protect your data

No advanced math, no magic — just clear concepts.

Why Understanding Git Internals Matters

When you understand Git internally:

• You stop guessing and start reasoning

• Commands make logical sense

• Debugging Git issues becomes easier

• You rely less on memorization

Think of this as learning how Git thinks.

What Is the .git Folder?

When you run:

git init

Git creates a hidden folder called:

.git/

This folder is the heart of Git.

Important Rule

👉 Your project is not a Git repository because of Git commands —
it’s a repository because the .git folder exists.

Delete .git, and Git forgets everything.

What’s Inside the .git Folder?

A simplified view:

.git/
├── objects/
├── refs/
├── HEAD
├── index
├── config

Let’s focus on the most important parts.

1. objects/ – Where Git Stores Everything

This is Git’s database.

• Every file

• Every folder

• Every commit

All are stored here as objects.

2. HEAD – Where You Are Right Now

HEAD points to:

• The current branch

• The latest commit on that branch

Think of it as:

“You are here 📍”

3. index – The Staging Area

The index file represents:

• What will go into the next commit

This is why staging exists.

Git Objects: The Building Blocks 🧱

Git stores data using four object types, but three are core:

1. Blob

2. Tree

3. Commit

Let’s break them down.

1. Blob (File Content)

A blob stores:

• File content only

• No filename

• No directory info

Example:

"Hello Git"

That text becomes a blob object.

💡 If two files have the same content → Git stores only one blob.

2. Tree (Folder Structure)

A tree represents:

• A directory

• Filenames

• File permissions

• Links to blobs or other trees

Think of a tree as:

A folder pointing to files and subfolders

3. Commit (Snapshot + Metadata)

A commit stores:

• A reference to a tree

• Parent commit(s)

• Author info

• Timestamp

• Commit message

A commit does not store files directly.

Relationship Between Commit, Tree, and Blob

Commit
  ↓
 Tree
  ↓
Blobs (file contents)

This structure makes Git fast, efficient, and reliable.

How Git Tracks Changes (Not Diffs!)

Here’s a key idea:

🚫 Git does not primarily store diffs
✅ Git stores snapshots

Each commit:

• Points to a full snapshot of the project

• Reuses unchanged objects from previous commits

That’s why Git is fast and space-efficient.

What Happens Internally During git add?

When you run:

git add file.txt

Git does the following:

1. Reads file content

2. Creates a blob object

3. Stores it in .git/objects

4. Updates the index (staging area)

👉 No commit yet
👉 Just preparation

What Happens Internally During git commit?

When you run:

git commit -m "Add file"

Git:

1. Reads the staging area (index)

2. Creates a tree object

3. Creates a commit object

4. Moves HEAD to the new commit

🎉 Your snapshot is now permanent.

How Git Uses Hashes (Integrity & Safety)

Every Git object is identified by a SHA-1 hash.

Example:

e83c5163316f89bfbde7d9ab23ca2e25604af290

This hash is based on:

• Object content

• Object type

Why This Matters

• Change the content → hash changes

• Corruption is instantly detectable

• History cannot be silently altered

Git is self-verifying by design.

The Mental Model to Remember 🧠

Instead of memorizing commands, remember this:

• Git stores objects

• Objects are connected by hashes

• Commits point to trees

• Trees point to blobs

• git add prepares

• git commit records

Once this clicks, Git feels logical — not magical.

This article explains what Git is, why it’s used, and how to use it step by step, even if you’re completely new.

What is Git?

Git is a distributed version control system.

In simple terms:

• It tracks changes in your files

• It lets you save versions of your project

• It allows multiple developers to work on the same code without conflicts

Unlike older systems, Git gives every developer a full copy of the project history on their own machine.

Why is Git Used?

Git is used because it helps developers:

• ✅ Track who changed what and when

• ✅ Roll back to earlier versions if something breaks

• ✅ Work on features without affecting the main code

• ✅ Collaborate efficiently with teams

• ✅ Maintain a clean and reliable project history

Whether you’re working solo or in a team, Git is essential.

Git Basics & Core Terminologies

Before running commands, let’s understand some key Git concepts.

Repository (Repo)

A repository is a project folder that Git is tracking.

It contains:

• Your project files

• A hidden .git directory that stores history and metadata

Commit

A commit is a snapshot of your project at a specific point in time.

Think of it like:

“Save game” 🎮 for your code

Each commit has:

• A unique ID (hash)

• A message describing the change

Branch

A branch lets you work on features independently.

• main (or master) → stable code

• feature branches → experiments or new features

HEAD

HEAD is a pointer to the current commit you’re working on.

Usually, it points to the latest commit on the current branch.

Git works in three main areas:

1. Working Directory – where you edit files

2. Staging Area – where you prepare files for commit

3. Repository – where commits are permanently stored

Common Git Commands (With Examples)

Let’s see the most important Git commands used daily.

1. git init

Creates a new Git repository.

git init

Use this inside your project folder.

2. git status

Shows the current state of your files.

git status

It tells you:

• Which files are modified

• Which files are staged

• What’s not tracked yet

3. git add

Moves changes to the staging area.

git add file.txt

Or add everything:

git add .

4. git commit

Saves staged changes to the repository.

git commit -m "Add initial project files"

💡 Always write clear commit messages.

5. git log

Shows the commit history.

git log

You’ll see:

• Commit IDs

• Author

• Date

• Commit message

6. git branch

Lists or creates branches.

git branch

Create a new branch:

git branch feature-login

7. git checkout

Switch between branches.

git checkout feature-login

(Modern alternative: git switch)

A Simple Git Workflow (From Scratch)

Let’s walk through a basic developer workflow.

mkdir my-project
cd my-project
git init

Create a file:

echo "Hello Git" > readme.txt

Check status:

git status

Stage the file:

git add readme.txt

Commit:

git commit -m "Add readme file"

Check history:

git log

🎉 You’ve successfully used Git!