Forem: Pratham

Emmet for HTML: A Beginner’s Guide to Writing Faster Markup

Pratham — Sun, 01 Feb 2026 18:12:23 +0000

Prerequisites: You know what HTML tags are (<div>, <p>, <ul>).
Audience: Developers who are tired of typing < and > a thousand times a day.

The Root: The "Carpal Tunnel" Problem

Writing HTML the "old school" way is painful. It feels like this:

Type <
Type d, i, v
Type >
(Editor adds closing tag </div>)
Move cursor inside.
Type <...

It’s slow. It breaks your thought process. You spend more time pressing Shift + , than actually building your website.

The Solution? Texting Shortcuts.

Remember how you text?

You type "omg" → Phone corrects to "Oh my god"
You type "brb" → Phone corrects to "Be right back"

Emmet is exactly this, but for HTML.
It is a plugin built into almost every modern code editor (VS Code, Sublime, Atom).

You type a short abbreviation, hit Tab, and Emmet expands it into full, valid HTML code.

The Trunk: The Core Abbreviations

Let's learn the basic "vocabulary" of Emmet. The beauty is that it reuses the CSS syntax you already know.

1. The Tag (The Species)

Just type the tag name. No brackets.

You Type: div
You Press: Tab
Emmet Writes: <div></div>
You Type: h1
Emmet Writes: <h1></h1>

2. The Class (The Dot `.`)

Just like in CSS, a dot means "Class".

You Type: .container
Emmet Writes: <div class="container"></div>
(Note: If you don't specify a tag, Emmet assumes it's a div)
You Type: p.text-bold
Emmet Writes: <p class="text-bold"></p>

3. The ID (The Hash `#`)

Just like in CSS, a hash means "ID".

You Type: #navbar
Emmet Writes: <div id="navbar"></div>
You Type: form#login
Emmet Writes: <form id="login" action=""></form>

4. The Combination (Mixing Them)

You can chain them together like a sentence.

You Type: button.btn#submit
Emmet Writes: <button class="btn" id="submit"></button>

Diagram: The Expansion Flow

YOUR FINGERS                     THE EDITOR (EMMET)
    │                                    │
    ▼                                    ▼
Type: "ul.list"  ───────────────▶  detects ".list" (Class)
    │                              detects "ul" (Tag)
    │                                    │
    ▼                                    ▼
Press: [TAB]     ───────────────▶  EXPANDS TO:
    │                              <ul class="list">
    │                                  | (Cursor lands here)
    │                              </ul>

The Branches: Advanced Power Moves

Okay, saving a few keystrokes is nice. But now let's look at the features that make you look like a wizard.

5. Multiplication (`*`)

This is the "Copy-Paste" killer.
Need a list with 5 items? Don't copy-paste <li> 5 times. Multiply it.

You Type: li*5

Emmet Writes:

<li></li>
<li></li>
<li></li>
<li></li>
<li></li>

6. The Child (`>`) aka Nesting

This puts elements inside other elements. Think of it like a Russian Doll.

You Type: ul>li
Translation: "Make a ul, and put an li inside it."
Emmet Writes:
```
<ul>
    <li></li>
</ul>
```

Combo Move (The Classic Menu):

You Type: ul>li*3

Emmet Writes:

<ul>
    <li></li>
    <li></li>
    <li></li>
</ul>

7. The Sibling (`+`) aka The Neighbor

This puts elements next to each other, not inside.

You Type: h1+p
Translation: "Make an h1, then place a p right after it."
Emmet Writes:
```
<h1></h1>
<p></p>
```

8. Grouping (`()`) aka The Math Logic

Sometimes you need to group logic together.
"I want a Header with a Logo... AND THEN a Main section."

You Type: (header>h1)+main

Emmet Writes:

<header>
    <h1></h1>
</header>
<main></main>

(Without brackets, the main would end up inside the h1! Brackets keep the hierarchy clean.)

The Ultimate Shortcut: The Boilerplate (!)

Every HTML file starts the same way: <!DOCTYPE html>, <html>, <head>, <body>...
It's boring to type.

Emmet solves this with one character.

You Type: !
You Press: Tab
Emmet Writes:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <!-- Cursor lands right here! -->
</body>
</html>

This is the first thing you should do in every new HTML file.

Summary Cheat Sheet

Symbol	Name	Meaning	Example	Result
.	Class	"Wear this uniform"	`.box`	`<div class="box"></div>`
#	ID	"Your ID card"	`#nav`	`<div id="nav"></div>`
>	Child	"Go inside"	`div>p`	`<div><p></p></div>`
+	Sibling	"Stand next to"	`h1+h2`	`<h1></h1><h2></h2>`
*	Multiply	"Clone yourself"	`p*3`	3 paragraphs
$	Number	"Count 1, 2, 3..."	`li.item$*3`	`<li class="item1">... item2... item3`
{}	Content	"Fill with text"	`p{Hello}`	`<p>Hello</p>`

Conclusion: Speed is a Byproduct

You might think using Emmet is just about showing off speed. It's not.

It's about removing friction.

When you don't have to think about typing brackets, closing tags, and quotes, your brain is free to think about the Structure and the Design.

Start small.

Use ! for your layout.
Use . for your classes.
Use > for your lists.

Before you know it, you'll be writing HTML as fast as you can think.

Happy Coding!

Found this helpful? This is part of the "Unboxed" series where we break down web tech from first principles.

CSS Selectors 101: Targeting Elements with Precision

Pratham — Sun, 01 Feb 2026 18:08:44 +0000

Prerequisites: Basic knowledge that "HTML is the structure" and "CSS is the style."
Audience: Developers who blindly copy-paste selectors without knowing why they work (or don't work).

The Root: The "Crowded Room" Problem

Imagine you are standing on a stage in front of a massive, crowded hall.
There are 1,000 people in the room.

Some are Waiters.
Some are Cooks.
Some are Guests.
One person is the Manager.

Your job is to give instructions. You have a microphone (CSS), and you need to tell specific people to "Wear a Red Hat" (Apply a Style).

If you just shout into the mic:

"WEAR A RED HAT!"

Chaos ensues. All 1,000 people—waiters, cooks, the manager, the guests—put on a red hat. The room looks ridiculous.

You need a way to point. You need a way to say:

"Only the Waiters..."
"Only Dave..."
"Only the Cooks who are inside the Kitchen..."

In the world of Web Development, this "Pointing Finger" is the CSS Selector.

Without selectors, you can only style everything or nothing.
With selectors, you become a sniper. You target exactly the element you want, and ignore the rest.

The Trunk: The Three Pillars of Targeting

There are three fundamental ways to point at elements. Master these, and you master 90% of CSS.

1. The Element Selector (The "Megaphone Shout")

This is the broadest, loudest way to target. You call out the biological species of the element.

HTML: <p>, <div>, <h1>, <button>
The Shout: "HEY, HUMANS!" (or "HEY, PARAGRAPHS!")

When you use an element selector, you are targeting every single instance of that tag on the page.

The Code:

p {
  color: blue;
}

The Translation:

"I don't care who you are, what your name is, or where you are sitting. If you are a Paragraph (<p>), turn blue."

When to use it: When you want to set the "Base Laws" of your reality.

"All text should be dark grey."
"All links should be underlined."

2. The Class Selector (The "Uniform")

This is the most common, flexible tool in your kit. Behaving like a logical group or a job title.

Imagine giving 50 people in the crowd a Green Apron. You don't know their names, but you know they are part of the "Kitchen Staff."

HTML: class="kitchen-staff"
The Shout: "HEY, KITCHEN STAFF!"

The Code:

/* Note the dot (.) before the name */
.kitchen-staff {
  background-color: green;
}

The Translation:

"I don't care if you are a man, woman, tall, or short. If you are wearing the 'kitchen-staff' uniform (class), turn green."

Why it's powerful:

Reusable: You can give the same class to 100 different elements.
Mixable: One element can have multiple classes (e.g., class="kitchen-staff manager-role").

The Analogy:
It's a Nametag. Anyone can wear a nametag that says "Visitor". If 50 people wear it, styles apply to all 50.

3. The ID Selector (The "Passport Number")

This is the nuclear option. It targets ONE specific individual.

In a room of 1,000 people, there might be many "Davids," but there is only one specific David with Passport ID: D-12345.

HTML: id="main-logo"
The Shout: "HEY YOU, WITH ID 'MAIN-LOGO'!"

The Code:

/* Note the hash (#) before the name */
#main-logo {
  height: 100px;
}

The Translation:

"I am looking for the ONE, UNIQUE element with the ID main-logo. Apply this height."

The Golden Rule:
ID means Identity. It must be unique.

Wrong: Two people having the same Passport Number.
Wrong: Two HTML elements having id="header".

When to use it:
Rarely. Use it for "Landmark" elements that only exist once, like The Header, The Footer, or The Main Sidebar. In modern development, we prefer Classes over IDs because Classes are reusable. ID is too specific (more on that later).

Diagram: The Targeting Hierarchy

TARGETING SCOPE
(Who listens when you shout?)

   BROADEST
  ┌───────────────────────┐
  │   ELEMENT SELECTOR    │  "Humans!" (p, div, h1)
  │    (The Entire Population) │
  └───────────┬───────────┘
              │
              ▼
  ┌───────────────────────┐
  │    CLASS SELECTOR     │  "Waiters!" (.btn, .card)
  │    (The Specific Group)    │
  └───────────┬───────────┘
              │
              ▼
  ┌───────────────────────┐
  │     ID SELECTOR       │  "John Smith!" (#header)
  │   (The Unique Individual)  │
  └───────────────────────┘
    NARROWEST

The Branches: Advanced Logic

Now that you know the basics (The Trunk), let's add some logic (The Branches) to handle complex situations.

4. The Grouping Selector (The "Meeting")

Sometimes, you want to give the same instruction to two different groups.

Instead of writing:

"Waiters, wear black shoes."
"Cooks, wear black shoes."

You can say:

"Waiters AND Cooks, wear black shoes."

The Code (The Comma):

/* The comma literally means "AND" */
h1, h2, .subtitle {
  font-family: 'Arial', sans-serif;
}

The Logic:
Target group A, AND group B, AND group C.

5. The Descendant Selector (The "Inside" Rule)

This is where things get interesting. This selector cares about Location.

Imagine you have "Chairs" in the Dining Room and "Chairs" in the Garden.
You want to paint only the Garden chairs white.

If you just target chair, you start painting the dining room too.
You need to say: "Find the Chairs that are INSIDE the Garden."

The Code (The Space):

/* Note the space between words */
.garden .chair {
  color: white;
}

The Translation:

First, find the .garden.
Inside it, look for any .chair.
Style only those chairs.

Analogy:

"Address the letter to: John (Selector 2) who lives at 123 House (Selector 1)."

If John is walking down the street (outside the house), the letter doesn't go to him. It only goes to the John inside the house.

A Quick Note on Priority (Specificity)

What happens if you give conflicting orders?

Order 1 (Class): "All .waiters wear Blue shirts."
Order 2 (ID): "The Head Waiter (#head-waiter) wear a Red shirt."

The Head Waiter is also a waiter. He has both the class and the ID. Which shirt does he wear?

The Rule of Specificity:
The more specific order wins.

ID (Personal Order) beats Class.
Class (Group Order) beats Element.
Element (General Law) is the weakest.

So, the Head Waiter wears Red. A personal order overrides a group order.

Conclusion: Taming the Chaos

CSS without selectors is like trying to organize a library by throwing books into a pile.

Element Selector: Set the baseline (The species).
Class Selector: Create your reusable styles (The uniforms). (Use this 90% of the time!)
ID Selector: Pinpoint unique landmarks (The passport).
Descendant Selector: Context matters (Targeting based on location).

Next time you write CSS, don't just guess. Close your eyes and visualize the room. Are you shouting at the species? Are you calling a group? or are you pinpointing an individual?

Point with precision.

Found this helpful? This is part of the "Unboxed" series where we break down web tech from first principles.

Understanding HTML: The Invisible Skeleton of the Web

Pratham — Sun, 01 Feb 2026 18:01:11 +0000

Prerequisites: None.

Audience: Beginners who want to understand the "Physics" of the web, not just the code.

1. The Hook: The Skeleton Beneath the Skin

Open any website (YouTube, Google, Spotify). It looks polished, colorful, and alive.

Now, imagine stripping away the paint (colors), the movement (animations), and the logic (buttons working).
What is left?

The Structure.

Just like a human body has a skeleton to hold the muscles and skin, every webpage has HTML (HyperText Markup Language). Without it, the web would just be a shapeless pile of text.

We will use the Tree Principle to unbox this:

Roots: What is HTML really? (It's not programming).
Trunk: The Anatomy of an Element (The Box).
Branches: The Two Rules of Layout (Block vs. Inline).

2. The Roots: It's Not "Code", It's Layout

First, a professional distinction: HTML is not a programming language.
It doesn't calculate math (1 + 1). It doesn't have logic (if this, then that).

It is a Markup Language.
Think of it like a teacher marking up a student's essay with a red pen.

"This sentence is a Heading."
"This word should be Bold."
"This here is an Image."

HTML tells the browser what things are, not what they do.

3. The Trunk: Anatomy of an Element (The Box)

The most common confusion for beginners is the difference between a Tag and an Element.

The Distinction

The Tag (<p>): This is the Label. It’s the instruction you give to the browser.
The Element (<p>Hello</p>): This is the Result. It is the entire object that the browser builds.

Analogy: The Magic Moving Box

Opening Tag <p>: You open a cardboard box and write "Paragraph" on the side.

Content Hello: You put the word "Hello" inside the box.

Closing Tag </p>: You close the flaps and tape it shut.

The Whole Box (Cardboard + Tape + Content) is the "Element".

Visual: Anatomy of an Element

[   <p>   ]   +   [   Hello   ]   +   [   </p>   ]
(Opening Tag)       (Content)         (Closing Tag)
      \______________________________________/
                    The Element

The Void Elements (Self-Closing)

Some boxes cannot be opened. They are solid objects.
Example: <img>, <br>, <input>.

We call these Void Elements or Self-Closing Tags.

Why? You can't put text inside an image. The image is the content.
Syntax: <img src="cat.jpg" /> (The / at the end is optional in modern HTML5, but good practice).

4. The Branches: The Laws of Physics (Block vs. Inline)

Once you create these boxes (Elements), how does the browser pile them up?
Does it stack them? Or does it line them up?

There are two fundamental types of elements. Understanding this solves 90% of your future CSS headaches.

1. Block-Level Elements (`div`, `h1`, `p`, `section`)

The Rule: "I own this row."

Behavior: A block element always starts on a new line and takes up the full width available (100% of the screen), even if it only has one word in it.
Analogy: Shipping Crates.
If you put a shipping crate in a hallway, nobody can stand next to it. They have to wait behind it.
```

<div>Box 1</div>
<div>Box 2</div>
<div>Box 3</div>
```

2. Inline Elements (`span`, `a`, `b`, `strong`)

The Rule: "I just fit in."

Behavior: An inline element only takes up as much width as necessary. It does not start a new line. It flows with the text.
Analogy: Words in a Sentence.
If you highlight a word in yellow, it doesn't break the sentence. It just sits there, side-by-side with other words.
```

<p>This is a <strong>bold</strong> word and a <a href="#">link</a> in a sentence.</p>
```

Visual: The Flow

1. Block Level (The Stack)
   +---------------------------------------+
   |  Heading 1: <h1>                      |
   +---------------------------------------+
   |  Paragraph: <p>                       |
   +---------------------------------------+
   |  Container: <div>                     |
   +---------------------------------------+

2. Inline Level (The Flow)
   [Word 1: <span>]  [Word 2: <b>]  [Word 3: <a>]

5. The Leaves: Professional Depth (Semantics)

"If <div class="header"> and <header> do the exact same thing visually, why do we have both?"

This is the difference between an amateur and a pro.

The Problem with `<div>` (The Generic Box)

A <div> is a box with no meaning. It tells the browser "There is a group of stuff here," but it doesn't say what that stuff is.

Semantic HTML (The Meaningful Box)

Tags like <article>, <nav>, <aside>, and <footer> mean something.

Accessibility: Screen Readers (for blind users) use these tags to navigate. "Jump to Navigation" works only if you used <nav>, not <div class="nav">.
SEO (Search Engines): Google prefers <article> because it knows that's where the real content is.

Analogy: The Label Maker

Non-Semantic (div): Labeling every box in your garage "Stuff". You have to open every box to find the Christmas lights.

Semantic (nav, article): Labeling boxes "Kitchen", "Garage", "Christmas". You know exactly where to look.

6. Conclusion: Build Better Skeletons

HTML is simple to learn but hard to master.

Remember the Box: Every element is a box.
Remember the Flow: Blocks stack; Inline flows.
Be Descriptive: Use the right label for the right box.

Open your browser right now. Right-click this page and select "Inspect".
You will see the skeleton. You will see the boxes. And you will see the web for what it truly is.

The Invisible Skeleton.

How a Browser Works: The Invisible Factory Inside Your Screen

Pratham — Sun, 01 Feb 2026 17:53:31 +0000

Prerequisites: You know how to type a URL and hit Enter.

Audience: Developers who want to move beyond "It just works" and understand the machinery that turns code into pixels.

1. The Hook: The "Black Box" Moment

You sit down at your computer. You type google.com. You press Enter.

In less than a second—often just 500 milliseconds—a blank white screen transforms into a colorful, interactive world. Buttons appear. Images load. Animations play.

To most of us, this is just... normal.

But if you stop and think about it, it's a miracle. You sent a request across the ocean, fetched a bunch of text files (HTML, CSS, JS), and your computer somehow knew exactly where to place every single pixel on your 4K screen.

We usually treat the browser like a "Black Box":
Code goes in (index.html) → Magic happens → Website comes out.

Today, we are going to smash that black box open. We are going to see the gears, the workers, and the assembly lines inside. We won't just learn what happens; we'll learn why performance bottlenecks exist and how professional engineers optimize for them.

We will use the Tree Principle to understand this without getting lost in the details:

Roots: Why do we even need a browser engine? (The Problem)
Trunk: The High-Level Components (The Factory Structure)
Branches: The Critical Rendering Path (The Assembly Line)

2. The Roots: The Problem of Translation

Computers vs. Humans

The fundamental problem the browser solves is a Language Barrier.

Computers speak Math. They understand binary, coordinates, and logic.
Humans speak Visuals. We understand layouts, colors, and flow.

If you sent raw HTML to your screen, it wouldn't know what to do. The screen is just a grid of millions of tiny lights (pixels). It needs to know: "Turn pixel (100, 200) Red."

HTML doesn't say "Turn pixel (100, 200) Red."
HTML says <h1>Hello World</h1>.

The Browser is the Translator.
Its job is to read your abstract "Blueprints" (HTML/CSS) and translate them into Rasterization Commands (painting instructions) for the screen.

Analogy: The Invisible Factory
Imagine your computer is a massive construction site.

You (The User) are the Client. You asked for a specific building ("google.com").

The Server is the Architect. It sends over the Blueprints (HTML/CSS).

The Browser is the Construction Company. It has a Manager, a specialized Crew (Threads), and Robots (JIT Compiler) to build that house on your screen in milliseconds.

3. The Trunk: The Factory Managers (High-Level Architecture)

Before we start building, let's meet the crew. A browser isn't just one program; it's a multi-process system designed for speed and security.

The 7 Key Components

The User Interface (The Dashboard):
This is the part you actually see: The address bar, the back button, the bookmarks menu.
- Role: It's the control panel for the human. It takes your orders and communicates them to the engine.
The Browser Engine (The Site Manager):
- Role: The boss. It stands between the UI (you) and the Rendering Engine (the workers). It marshals commands. When you type in the address bar, the Browser Engine determines if it's a search query or a URL and directs the Networking team accordingly.
The Rendering Engine (The Construction Crew):
- Role: The Star of the Show. It interprets HTML/CSS and paints pixels.
- The Main Thread: Most of the work happens here. Parsing, Layout, and JS execution all fight for time on this single thread. If this thread gets blocked (e.g., by heavy JS), your page freezes.
- Examples: Chrome uses Blink, Safari uses WebKit, Firefox uses Gecko.
Networking (The Supply Trucks):
- Role: The logistics team. It handles HTTP requests, DNS resolution, and TCP connections.
- Optimization: Modern browsers parallelize these requests (sending multiple trucks at once) to fetch files faster.
JavaScript Engine (The Brains):
- Role: The logic center.
- How it works: It uses JIT (Just-In-Time) Compilation. It doesn't just read code; it compiles it into machine code while the program is running to make it blazing fast.
- Examples: Chrome uses V8, Firefox uses SpiderMonkey.
UI Backend (The Painter):
- Role: The basic drawing tools provided by your Operating System. The browser uses these to draw standard widgets like select boxes and window frames.
Data Persistence (The Warehouse):
- Role: Storage. Cookies, LocalStorage, IndexedDB.

Visual: The Factory Map

      [ User ]
         |
    (Interacts)
         v
[ User Interface ]
         |
     (Commands)
         v
+---- THE FACTORY (Browser Engine) ---------------------------+
|                                                             |
|  Controls --> [ Rendering Engine (The Crew) ] <-------+     |
|                       |            |                  |     |
|  Requests --> [ Networking ]       +--[ JS Engine ]   |     |
|                       |                               |     |
|  Stores   --> [ Data Persistence ]                    |     |
|                                                       |     |
+-------------------------------------------------------+-------+
                        ^                               |
                        +----(Fetches HTML/CSS)---------+

Key Takeaway: The Rendering Engine (Pink box) is where variables become visuals.

4. The Branches: The Critical Rendering Path

This is the assembly line. The moment data arrives, the Rendering Engine starts a sprinting process called the Critical Rendering Path.

We will break it down into 5 Steps.

Step 1: Parsing HTML (Building the Frame)

The browser receives raw bytes of HTML.
Wait... -> Byte Stream -> Characters -> Tokens -> Nodes -> DOM.

The Result: The DOM (Document Object Model).
Analogy: The DOM is the Steel Frame of the building. It captures the hierarchy (parent/child relationships) perfectly.
Professional Note: HTML parsing is incremental. The browser starts building the DOM before the entire file has arrived. This is why you see content appearing piece-by-piece on slow connections.

Step 2: Parsing CSS (The Interior Design)

The browser finds a <link> tag and fetches CSS. Unlike HTML, CSS cannot be incremental.

Why? CSS rules cascade. A rule at the bottom of the file (body { font-size: 20px }) can override a rule at the top (body { font-size: 12px }). If the browser rendered incrementally, the text would snap from small to big (a bad user experience).
The Result: The CSSOM (CSS Object Model).
Blocking: Rendering is blocked until the CSSOM is built.

Step 3: The Render Tree (The Construction Plan)

Now we have the Structure (DOM) and the Style (CSSOM).
The browser combines them into the Render Tree.

The Filter: The Render Tree ONLY contains things that will be visible.
Example:
- <head> tags? No (Invisible).
- display: none elements? No (Removed from tree).
- visibility: hidden elements? Yes (They take up space, even if empty).
- ::before pseudo-elements? Yes (They exist in Render Tree but not DOM).

Analogy: The Construction Manager creates the final "To-Build" list. He scratches out anything marked "Hidden" but keeps the "Transparent" glass windows (visibility: hidden) because they still need a frame.

Step 4: Layout (The Geometry Phase)

Also known as Reflow. The browser calculates the exact geometry of every visible object.

The Math: It traverses the Render Tree recursively. "Container is 1000px. Left child is 50%. So Left child is 500px."
Coordinate System: It maps everything to specific (x,y) coordinates on the viewport.
Performance Cost: Layout is expensive. It runs on the Main Thread. Complexity correlates with the number of DOM nodes.

Analogy: "Arranging the Furniture."
You measure the room. You decide the sofa goes at (x: 50, y: 100). If you shove the sofa, you might bump the table. One change usually causes a chain reaction of movements.

Step 5: Paint (The Texture Phase)

Now we have coordinates. The browser typically divides the page into Tiles (squares) and creates a list of drawing commands for each tile.

Action: "Fill this rectangle #F00." "Draw text 'Hello' here."
Result: Millions of colored pixels. This is called Rasterization.

Step 6: Composition (The Assembly Phase)

This is the modern magic. Browsers don't paint everything onto one canvas. They paint different elements onto separate Layers.

Main Layer: The background and standard text.
Promo Layer: A menu that slides in.
Video Layer: A 3D transform element.

The Compositor Thread (running on the GPU) takes these painted layers and stacks them together to create the final frame.

Why this matters: When you scroll, the browser doesn't re-paint. It just moves the existing layers around. This is why scrolling is smooth (60fps) even on heavy sites.

5. The Leaves: Optimization & Dynamics

Now that the factory is running, how do we keep it fast?

Reflow (Layout) vs. Repaint vs. Composite

As a developer, this is the hierarchy of cost:

Reflow (Layout Change) - $$$
- Action: Changing width, height, margin.
- Consequence: The browser must re-calculate geometry, then re-paint, then re-composite. The "Main Thread" is blocked.
- Analogy: Moving walls in the house.
Repaint (Visual Change) - $$
- Action: Changing color, background-color.
- Consequence: Geometry stays the same. The browser skips Layout but must re-rasterize the pixels.
- Analogy: Re-painting the wall.
Composite (GPU Change) - $ (Free)
- Action: Changing transform, opacity.
- Consequence: The Main Thread is bypassed! The GPU just moves the existing layer.
- Analogy: Sliding a photo across a table.

Pro-Tip: Use will-change: transform to hint to the browser: "Put this on its own layer, I'm about to move it."

Visual: The Full Pipeline

[ HTML ] --(Parse)--> [ DOM Tree ]
                                  \
                                   (Combine) --> [ RENDER TREE ]
                                  /                   |
[ CSS ] --(Parse)--> [ CSSOM    ]                     | (Geometry)
                                                      v
                                                 [ LAYOUT ]
                                                      | (Rasterize)
                                                      v
                                                  [ PAINT ]
                                                      | (GPU)
                                                      v
                                                [ COMPOSITE ]

6. Conclusion: The Miracle in 500ms

So, let's smash that "Black Box" one last time.

When you type google.com:

Roots: You requested a building.
Trunk: The Browser Engine woke up the Rendering Engine (Main Thread) and the Networking team.
Branches:
- Networking fetched the HTML blueprints (in parallel).
- HTML parsed into DOM (Steel Frame).
- CSS parsed into CSSOM (Design Notes).
- Combined into Render Tree (Construction Plan).
- Calculated Layout (Measured the room).
- Rasterized pixels into Layers (Painted tiles).
- Composited layers via GPU (Final Assembly).

And it did all of this before you could even blink.

Next time you write a line of CSS, remember: You aren't just styling text. You are giving instructions to a massively complex, multi-threaded engine. Treat it with respect, optimize for the Composite step, and keep your Main Thread light.

Unbox the magic.

TCP vs UDP: The Rules of the Digital Road (And Where HTTP Fits)

Pratham — Sun, 01 Feb 2026 17:40:02 +0000

Prerequisites: You know that computers send data (0s and 1s) to each other over the internet.

Audience: Developers and learners who want to understand the "Invisible Engines" of the internet.

1. The Roots: The Problem with the "Wild West" Internet

Imagine the internet not as a sleek, high-tech highway, but as a messy, crowded Post Office in a city with terrible traffic.

You want to send a 1,000-page book (your data) to a friend. You can't just teleport the book. You have to rip the pages out, put each one in a separate envelope (a Packet), and mail them.

The Chaos

In this raw, uncontrolled system (the "IP" or Internet Protocol layer):

Lost Envelopes: A mail truck crashes. Page 404 is gone forever.
Out of Order: The truck connecting Page 10 takes a highway. The truck carrying Page 2 takes a back road. Your friend receives Page 10 before Page 2.
No Feedback: You mail the envelopes and... silence. Did they get it? Did they burn it? You have no idea.

If you are sending a Mission Critical Legal Contract, this chaos is unacceptable.

If you are sending a Live Video Feed of a Cat, losing one frame (one envelope) doesn't matter; you just want the next frame immediately.

This fundamental difference in needs gave birth to two different managers for this post office: TCP and UDP.

2. The Trunk: Two Managers, Two Philosophies

To solve the chaos, we place a "Transport Protocol" on top of the raw internet. Think of these as two distinct shipping companies you can hire.

A. TCP (Transmission Control Protocol) - "The Obsessive Accountant"

Motto: "Better late than wrong."

TCP is the careful, reliable manager. When you hire TCP, they guarantee that every single byte arrives, and arrives perfectly in order.

How TCP Works (The "Connection" Concept):

The Handshake (The Setup): Before sending mail, TCP calls the receiver.
- Examples: "Are you ready? I am sending 100 pages." -> "Yes, I am ready." -> "Okay, starting now."
Numbering (Sequencing): TCP numbers every envelope (1/100, 2/100...).
Receipts (Acknowledgements - ACKs): For every batch of envelopes, the receiver must send a signed receipt. "I got pages 1-10. Send me 11."
Resending (Retransmission): If the receipt doesn't arrive, TCP assumes the worst and automatically re-sends that batch.

The Cost: This takes time. All that "Calling first" and "Waiting for receipts" makes TCP slower.

B. UDP (User Datagram Protocol) - "The Speed Demon"

Motto: "Move fast and break things."

UDP is the adrenaline-junkie courier. When you hire UDP, they grab your envelopes and throw them onto the trucks immediately.

How UDP Works:

No Handshake: No "Hello", no "Are you ready?". Just throw the data.
No Receipts: They don't care if it arrived.
No Retries: If a packet drops, it's gone.

The Benefit: It is blazing fast. There is zero "overhead" or waiting.

3. The Branches: The Deep Dive Comparison

Let's break down the differences with a detailed real-world scenario.

Scenario 1: Developing a Chat App (WhatsApp/Discord Text)

Requirement: You type "Hello". It is crucial that your friend sees "Hello". They cannot see "Hllo" or "elloH".
Choice: TCP.
Why: Reliability is more important than raw speed. A 50ms delay is imperceptible, but missing letters makes the app broken.

Scenario 2: Developing a Video Game (Call of Duty / Valorant)

Requirement: You shoot at an enemy. The server needs to know right now.
Choice: UDP.
Why: Speed is king.

With TCP: If a packet describing your position is lost, TCP pauses everything to re-request it. Your character freezes for 2 seconds (Lag Spike) while waiting for the old packet. This is unplayable.
With UDP: If the packet is lost, the server just misses your position for 0.01 seconds. The next packet arrives 0.01 seconds later with your new position. The game continues smoothly. Better to skip a frame than to pause the world.

Visual Comparison

graph TD
    subgraph TCP Process
    A[Sender] -->|SYN - Can we talk?| B[Receiver]
    B -->|SYN-ACK - Yes!| A
    A -->|ACK - OK!| B
    A -->|Data Packet 1| B
    B -->|ACK 1 - Got it!| A
    style A fill:#d4edda,stroke:#28a745
    style B fill:#d4edda,stroke:#28a745
    end

    subgraph UDP Process
    C[Sender] -->|Data Packet 1| D[Receiver]
    C -->|Data Packet 2| D
    C -->|Data Packet 3| D
    style C fill:#f8d7da,stroke:#dc3545
    style D fill:#f8d7da,stroke:#dc3545
    end

Table of Truth

Feature	TCP (Reliable)	UDP (Fast)
Connection	Established via 3-Way Handshake	None (Connectionless)
Reliability	Guarantees delivery (Retries lost data)	No guarantee (Fire & Forget)
Ordering	Guarantees correct order (1, 2, 3...)	Arrives in any order (1, 3, 2...)
Speed	Slower (Overhead of handshakes/ACKs)	Faster (Minimal overhead)
Use Cases	Web Browsing, Email, File Transfer, Text Chat	Streaming, VoIP calls, Online Gaming, DNS

4. The Leaves: Where HTTP Fits (The Application)

A common point of confusion for beginners: "Is HTTP a competitor to TCP? Do I choose between HTTP and TCP?"

NO. This is like asking, "Do I choose English or the Telephone?"

TCP is the Telephone (Steps 1-3 in diagram below). It establishes the line.
HTTP is the English Language (Steps 4-5). It is the actual conversation you have over the line.

The Stack Explained

HTTP (HyperText Transfer Protocol) is an Application Layer protocol. It defines what the data means (GET this page, POST this form).
But HTTP packets don't fly on their own. They are carried inside TCP packets.

Why does HTTP use TCP?
When you load a website (like Google.com), you need the HTML application to arrive perfectly. You don't want half the CSS file to be missing, or the JavaScript to arrive out of order (which would crash the page). Therefore, HTTP relies on TCP to handle the shipping.

(Note: Modern HTTP/3 actually uses UDP for speed, but that is an advanced optimization. The entire web was built on HTTP over TCP).

Visual: The "Packet Matryoshka Doll"

sequenceDiagram
    participant User
    participant Application_HTTP
    participant Transport_TCP
    participant Internet_IP

    User->>Application_HTTP: "Load Website"
    Note over Application_HTTP: Creates HTTP Request:<br/>"GET /index.html"

    Application_HTTP->>Transport_TCP: Here is my message. Send it safely.
    Note over Transport_TCP: Wraps HTTP in TCP.<br/>Adds Seq Numbers & Ports.<br/>Result: [TCP Header [HTTP Data]]

    Transport_TCP->>Internet_IP: Here is a segment. Route it.
    Note over Internet_IP: Wraps TCP in IP.<br/>Adds IP Addresses.<br/>Result: [IP Head [TCP [HTTP]]]

    Internet_IP->>Internet_IP: Sends across cables...

Summary Check

IP: The road system (Addressing).
TCP/UDP: The trucks (Transport & Reliability).
HTTP: The cargo inside the truck (The actual Website content).

5. Conclusion: The Tree of Knowledge

To summarize using our Tree Principle:

Roots (The Need): The internet is unreliable. We need rules to ensure data arrives correctly.
Trunk (The Solution): We have two main sets of rules:
- TCP: For when correctness is mandatory (Websites, Files).
- UDP: For when speed is mandatory (Streaming, Gaming).
Branches (The Details): TCP uses handshakes and receipts (ACKs). UDP just sends data.
Leaves (The Application): HTTP sits on top of TCP. It doesn't worry about lost packets because it trusts TCP to handle that dirty work.

Next Steps for You

Open your browser's Network Tab (F12). Reload a page. Look at the "Protocol" column. You'll likely see h2 (HTTP/2 over TCP) or maybe h3 (HTTP/3 over UDP - the future!).
Try using the ping command in your terminal (ping google.com). That uses ICMP, a cousin of UDP, to just check "Are you there?" without a full conversation.

Now you know not just what the acronyms mean, but why they exist in the first place.

TCP Explained: The Invisible Handshake Governing the Internet

Pratham — Sun, 01 Feb 2026 17:27:53 +0000

Prerequisites: Basic understanding that computers send "packets" of data.

Audience: Developers who want to understand how the internet ensures data actually arrives.

The Roots: The Problem with Shouting (Why We Need Rules)

Imagine you are in a crowded, noisy restaurant. You want to tell your friend a specifically ordered list of 10 movie recommendations.

If you just start shouting the names immediately ("UDP style"):

Scenario: You shout all 10 names at once.
The Problem:
- The waiter drops a tray (Noise/Packet Loss) -> Your friend misses name #3.
- You talk faster than they can write (Flow Control) -> They miss names #7, #8, #9.
- You say "The Matrix" then "Inception," but they hear "Inception" then "The Matrix" (Out of Order).
- Worst of all: You have no idea if they heard you. You just shouted and hoped for the best.

This is how the internet works by default (IP/UDP). It's fast, but it's chaotic.

The Solution: We need a strict set of rules—a Protocol—to ensure that:

We know the other person is ready to listen.
We know they heard exactly what we said.
If they missed something, we say it again.

Enter TCP (Transmission Control Protocol). Think of TCP not as a technology, but as a Reliable Project Manager for your data.

The Trunk: The 3-Way Handshake (Starting the Conversation)

Before any data (movie names) is exchanged, TCP requires a formal introduction. You don't just walk up to a stranger and whisper data. You establish a Connection.

This process is famous. It is called the 3-Way Handshake.

The Conceptual Analogy: The Phone Call

You: Dial the number. "Hello? Can you hear me?"
Friend: "Yes, I hear you. Can you hear me?"
You: "Yes, I hear you too. I'm going to start listing the movies now."

If any of these 3 steps fails, the conversation does not begin.

The Technical Reality: SYN, SYN-ACK, ACK

In the computer world, we use "Flags" (tiny distinct bits in the packet header) to indicate these states.

Step 1: The SYN (Synchronize)

Actor: Client (Your Browser)
Action: Sends a packet with the SYN flag turned on.
Meaning: "I want to synchronize numbers with you. Let's start a connection. My random ID (Sequence Number) is 100."
State: The Client is now in SYN_SENT state.

Step 2: The SYN-ACK (Synchronize-Acknowledge)

Actor: Server (Google/Facebook)
Action: Receives the SYN. Sends a packet with SYN AND ACK flags.
Meaning:
- ACK: "I Acknowledge your ID 100. The next one I expect is 101."
- SYN: "And I also need to synchronize my numbers. My random ID is 5000."
State: The Server is in SYN_RECEIVED state.

Step 3: The ACK (Acknowledge)

Actor: Client
Action: Receives the SYN-ACK. Sends a packet with just the ACK flag.
Meaning: "I Acknowledge your ID 5000. The next one I expect is 5001. The connection is established."
Result: ESTABLISHED. The "pipe" is now open. real data can flow.

Visual: The 3-Way Handshake

      CLIENT                                      SERVER
        |                                           |
        |--- SYN (Seq=100) ------------------------>|  (1. Client asks to connect)
        |                                           |
        |<-- SYN-ACK (Seq=5000, Ack=101) -----------|  (2. Server accepts & asks back)
        |                                           |
        |--- ACK (Ack=5001) ----------------------->|  (3. Client accepts Server)
        |                                           |
   ESTABLISHED                                 ESTABLISHED

The Branches: Reliability & Ordering (The Smart Part)

Now that the connection is open, how does TCP solve the problems of the "Shouting" method?

1. Verification (Sequence Numbers & ACKs)

Every single byte of data sent over TCP is numbered.

You send: "Here are bytes 1 to 100."
Receiver says: "ACK 101" (Meaning: "I got everything up to 100. I am ready for byte 101").

This is the Receipt. If you don't get a receipt, you assume the package was stolen/lost.

Visual: Normal Data Transfer

      CLIENT                                      SERVER
        |                                           |
        |--- Seq=101 ("Data: Hello") -------------->|
        |                                           |
        |<-- ACK=106 ("Got 5 bytes. Next?") --------|
        |                                           |
        |--- Seq=106 ("Data: World") -------------->|
        |                                           |
        |<-- ACK=111 ("Got 5 bytes. Next?") --------|

2. Retransmission (Handling Packet Loss)

This is TCP's superpower.

Scenario: You send bytes 1-100.
Event: A router crashes. The packet is destroyed.
Result: You (the Sender) start a stopwatch (Retransmission Timer).
Observation: "Hmm. I've been waiting 200ms and haven't received an ACK for those bytes."
Action: Retransmit! You send the exact same data again.

This ensures Reliability. The application (e.g., your web browser) never knows packet loss happened. TCP handled it silently in the background.

Visual: Packet Loss & Retransmission

      CLIENT                                      SERVER
        |                                           |
        |--- Packet A (Seq=100) ------------------->| (Arrives OK)
        |                                           |
        |--- Packet B (Seq=200) --X                 | (LOST IN TRANSIT!)
        |                         X                 |
        |<-- ACK=200 ("Got A. Expecting 200") ------|
        |                                           |
        | [Timer Ticking...]                        |
        | [Timer Ticking...]                        | (Client waits...)
        | [TIMEOUT!]                                |
        |                                           |
        |--- RETRANSMIT Packet B (Seq=200) -------->| (Sent Again)
        |                                           |
        |<-- ACK=300 ("Got B! Expecting 300") ------|

3. Ordering (Fixing the Timeline)

The internet is a web. Packet A might take a route via London, and Packet B might take a route via Tokyo. Packet B might arrive before Packet A.

UDP application: Plays the video frames out of order (Glitch).
TCP application: Looks at the Sequence Numbers. "I have packet 1 and packet 3. I am missing 2. I will hold packet 3 in a 'Buffer' (Waiting Room) until packet 2 arrives. Then I will give them to the user in order: 1, 2, 3."

The Leaves: Closing the Connection (The Polite Goodbye)

When the data transfer is done, we don't just walk away (which would leave the server waiting, wasting memory). We perform a 4-Way Handshake to close.

Client: Sends FIN (Finish). "I am done talking."
Server: Sends ACK. "Message received. Let me finish my work."
- (Server finishes sending any remaining data)
Server: Sends FIN. "Okay, I'm done talking too."
Client: Sends ACK. "Understood. Goodbye."

It takes 4 steps because TCP is a Full Duplex protocol—meaning connection can be closed in one direction while still open in the other (like hanging up the phone but still listening).

Visual: Connection Lifecycle

   CLOSED                                       CLOSED
     |                                            |
     | (1) 3-WAY HANDSHAKE                        |
     | <========================================> |
     |                                            |
   ESTABLISHED                                  ESTABLISHED
     |                                            |
     | (2) DATA TRANSFER                          |
     | =========================================> |
     |                                            |
     | (3) 4-WAY CLOSURE (Fin)                    |
     | <========================================> |
     |                                            |
   CLOSED                                       CLOSED

Summary: Why Developers Care

You generally don't touch TCP implementation in your code (Node.js or Python handles it). But understanding it explains "Why":

Why is http slower than udp? Because of the overhead: The 3-Way Handshake + Waiting for ACKs.
Why do WebSockets exist? To keep that expensive TCP connection open, instead of doing the 3-Way Handshake over and over for every message.
Why does my game lag? Because TCP is waiting for a lost packet to be retransmitted before showing you the current state (Head-of-Line Blocking).

Quick Recap Visual

SYN: "Hello?"
SYN-ACK: "Hello! I hear you."
ACK: "Great. Let's go."
SEQ/ACK: "Here is data 1." -> "Got 1, send 2."
FIN: "Bye."

TCP is the unsung hero that turns the chaotic wilderness of the internet into a reliable conversation.

Getting Started with cURL: A Beginner's Guide

Pratham — Sat, 31 Jan 2026 17:54:58 +0000

How do you talk to a server without opening a browser?

Every time you load a webpage, your browser sends a request to a server and gets a response. But what if you want to test an API? Debug a backend issue? Automate a task?

You need a way to send those requests directly. That's where cURL comes in.

What you'll learn:

What a server is and why we communicate with it
What cURL is and why programmers use it
How to make your first request
How to fetch and send data with APIs
Common mistakes and how to avoid them

Part 1: What is a Server? (Quick Context)

Before we dive into cURL, let's establish one concept.

The Client-Server Model

When you visit a website:

┌─────────────────────────────────────────────────────────────────────────────┐
│                        CLIENT-SERVER MODEL                                  │
└─────────────────────────────────────────────────────────────────────────────┘

    You (Client)                                           Server
    ┌────────────────┐                              ┌────────────────┐
    │                │    "Give me google.com"      │                │
    │    Browser     │ ────────────────────────────►│   Web Server   │
    │                │                              │   (Google)     │
    │                │    "Here's the webpage"      │                │
    │                │ ◄────────────────────────────│                │
    └────────────────┘                              └────────────────┘
          REQUEST               →                 →       RESPONSE

Client = The thing making the request (browser, app, your code)
Server = The thing responding with data

Why Talk to Servers?

As a Developer, You Might Need To...	Example
Test your API before building a frontend	"Does my /users endpoint work?"
Debug why a request is failing	"What status code is it returning?"
Automate tasks	"Download this file every hour"
Explore third-party APIs	"What does the GitHub API return?"

Browsers are great, but they add layers. Sometimes you need to talk to a server directly.

Part 2: What is cURL?

The Definition

cURL stands for "Client URL" — a command-line tool to transfer data to or from a server.

Think of it as a text-based browser. Instead of clicking buttons and seeing rendered pages, you type commands and see raw responses.

Why Not Just Use a Browser?

┌─────────────────────────────────────────────────────────────────────────────┐
│                    BROWSER vs cURL                                          │
└─────────────────────────────────────────────────────────────────────────────┘

    BROWSER                                         cURL
    ┌────────────────────────┐           ┌────────────────────────┐
    │ • Renders HTML/CSS     │           │ • Shows raw response   │
    │ • Runs JavaScript      │           │ • No rendering         │
    │ • Handles cookies      │           │ • Full control         │
    │ • Visual interface     │           │ • Scriptable           │
    │ • Hard to automate     │           │ • Easy to automate     │
    └────────────────────────┘           └────────────────────────┘

    Good for: Browsing                   Good for: Testing, debugging,
              as a user                           automation, APIs

Why Programmers Love cURL

Reason	Explanation
It's everywhere	Pre-installed on Mac, Linux, Windows 10+
It's scriptable	Put cURL in shell scripts for automation
It shows the truth	No rendering tricks—you see exactly what the server sends
It's fast	No browser overhead
It's precise	Full control over headers, method, body

Part 3: Your First cURL Command

Let's make your first request. Open your terminal.

The Simplest Command

curl https://example.com

What You'll See

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
    ...
</head>
<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents.</p>
    ...
</div>
</body>
</html>

What Just Happened?

┌─────────────────────────────────────────────────────────────────────────────┐
│                     YOUR FIRST cURL REQUEST                                 │
└─────────────────────────────────────────────────────────────────────────────┘

    Your Terminal                                      Server
    ┌────────────────┐                              ┌────────────────┐
    │                │    GET https://example.com   │                │
    │  curl command  │ ────────────────────────────►│  example.com   │
    │                │                              │                │
    │                │    200 OK + HTML content     │                │
    │                │ ◄────────────────────────────│                │
    └────────────────┘                              └────────────────┘

    1. You typed the command
    2. cURL sent an HTTP GET request
    3. The server responded with HTML
    4. cURL printed the response to your terminal

Congratulations! You just made an HTTP request without a browser.

Part 4: Understanding the Response

That HTML blob was the response body. But there's more to a response than just the body.

The Full HTTP Response

An HTTP response has three parts:

┌─────────────────────────────────────────────────────────────────────────────┐
│                    HTTP RESPONSE STRUCTURE                                  │
└─────────────────────────────────────────────────────────────────────────────┘

    ┌─────────────────────────────────────────────────────┐
    │  STATUS LINE                                        │
    │  HTTP/1.1 200 OK                                    │  ← Status code
    ├─────────────────────────────────────────────────────┤
    │  HEADERS                                            │
    │  Content-Type: text/html                            │  ← Metadata
    │  Content-Length: 1256                               │
    │  Date: Mon, 31 Jan 2026 17:30:00 GMT               │
    ├─────────────────────────────────────────────────────┤
    │  BODY                                               │
    │  <!doctype html>                                    │  ← The actual
    │  <html>                                             │     content
    │  ...                                                │
    └─────────────────────────────────────────────────────┘

Seeing Headers with -i

By default, cURL only shows the body. To see headers too:

curl -i https://example.com

Output:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256
Date: Mon, 31 Jan 2026 17:30:00 GMT
...

<!doctype html>
<html>
...

Understanding Status Codes

Code	Meaning	What It Means for You
200	OK	Request succeeded
201	Created	Resource created (after POST)
301/302	Redirect	Resource moved elsewhere
400	Bad Request	You sent invalid data
401	Unauthorized	Need to log in
403	Forbidden	Logged in but not allowed
404	Not Found	Resource doesn't exist
500	Internal Server Error	Server broke

Only Headers (No Body)

Sometimes you just want to check if a URL is alive:

curl -I https://example.com

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256

-I (capital I) = HEAD request, returns only headers.

Part 5: GET Requests — Fetching Data

What is GET?

GET = "Give me data"

It's the most common HTTP method. Every time you open a webpage, your browser sends a GET request.

cURL uses GET by default, so:

curl https://example.com
# Same as:
curl -X GET https://example.com

Working with APIs

APIs return JSON instead of HTML. Let's try a public API:

curl https://jsonplaceholder.typicode.com/users/1

Response:

{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "Sincere@april.biz",
  "address": {
    "street": "Kulas Light",
    "city": "Gwenborough"
  }
  ...
}

Making Output Cleaner

Silent mode (hide progress bar):

curl -s https://jsonplaceholder.typicode.com/users/1

Pipe to jq (format JSON beautifully):

curl -s https://jsonplaceholder.typicode.com/users/1 | jq

[!TIP]
jq is a JSON processor. Install it with brew install jq (Mac) or apt install jq (Linux) or choco install jq (Windows).

Query Parameters

Many APIs accept parameters in the URL:

curl "https://api.github.com/search/repositories?q=javascript&sort=stars"

[!NOTE]
Use quotes around URLs with special characters like ?, &, =.

Part 6: POST Requests — Sending Data

What is POST?

POST = "Take this data and do something with it"

Use POST when you want to:

Create a new resource
Submit a form
Send data to be processed

The Basic POST Command

curl -X POST https://jsonplaceholder.typicode.com/posts

But this sends an empty request. We need to add data.

Sending JSON Data

curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title": "My Post", "body": "Hello World", "userId": 1}'

Let's break this down:

Flag	Meaning
`-X POST`	Use POST method
`-H "Content-Type: application/json"`	Tell server we're sending JSON
`-d '{...}'`	The data to send

Response:

{
  "title": "My Post",
  "body": "Hello World",
  "userId": 1,
  "id": 101
}

The server created a resource and returned it with a new id!

Diagram: HTTP Request Structure

┌─────────────────────────────────────────────────────────────────────────────┐
│                    HTTP REQUEST STRUCTURE                                   │
└─────────────────────────────────────────────────────────────────────────────┘

    ┌─────────────────────────────────────────────────────┐
    │  REQUEST LINE                                       │
    │  POST /posts HTTP/1.1                               │  ← Method + Path
    ├─────────────────────────────────────────────────────┤
    │  HEADERS                                            │
    │  Host: jsonplaceholder.typicode.com                 │
    │  Content-Type: application/json                     │  ← What we're sending
    │  Content-Length: 52                                 │
    ├─────────────────────────────────────────────────────┤
    │  BODY                                               │
    │  {"title": "My Post", "body": "Hello World"}        │  ← The data
    └─────────────────────────────────────────────────────┘

Form Data (Alternative)

Some APIs expect form data instead of JSON:

curl -X POST https://httpbin.org/post \
  -d "username=john&password=secret"

This sends application/x-www-form-urlencoded data (like an HTML form).

Part 7: Talking to Real APIs

Let's practice with real, public APIs.

Example 1: Get Weather Data

# Free weather API (no key needed)
curl -s "https://wttr.in/London?format=3"

Output:

London: ☀️ +15°C

Example 2: GitHub User Info

curl -s https://api.github.com/users/torvalds | jq

Output (truncated):

{
  "login": "torvalds",
  "name": "Linus Torvalds",
  "company": "Linux Foundation",
  "followers": 200000,
  "public_repos": 7
}

Example 3: GitHub API with Authentication

Some APIs require authentication:

curl -H "Authorization: token YOUR_GITHUB_TOKEN" \
  https://api.github.com/user

Or using Basic Auth:

curl -u username:password https://api.example.com/protected

Where cURL Fits in Development

┌─────────────────────────────────────────────────────────────────────────────┐
│                   WHERE cURL FITS IN BACKEND DEVELOPMENT                    │
└─────────────────────────────────────────────────────────────────────────────┘

    Development Workflow:

    1. Build API endpoint
           │
           ▼
    2. Test with cURL ◄─── You are here!
           │
           ▼
    3. Write frontend code
           │
           ▼
    4. Write automated tests
           │
           ▼
    5. Deploy

    cURL is your quick testing tool before writing real code!

Part 8: Common Beginner Mistakes

Mistake 1: Forgetting the Protocol

# ❌ Wrong
curl example.com

# ✅ Correct
curl https://example.com

Why? cURL needs to know whether to use HTTP or HTTPS.

Mistake 2: Missing Content-Type Header

# ❌ Server might not understand your JSON
curl -X POST https://api.example.com/data -d '{"name":"John"}'

# ✅ Tell the server you're sending JSON
curl -X POST https://api.example.com/data \
  -H "Content-Type: application/json" \
  -d '{"name":"John"}'

Why? Without Content-Type, the server might parse your data incorrectly.

Mistake 3: Quote Issues on Windows

# ❌ Won't work on Windows CMD
curl -d '{"name":"John"}' https://api.example.com

# ✅ Use double quotes and escape inner quotes on Windows
curl -d "{\"name\":\"John\"}" https://api.example.com

Why? Windows CMD doesn't handle single quotes the same way.

Mistake 4: Not Reading Error Messages

$ curl https://api.example.com/protected
{"error": "Unauthorized", "message": "Missing authentication token"}

Read the response! It often tells you exactly what's wrong.

Mistake 5: SSL Certificate Errors

# If you see "SSL certificate problem"
# ❌ Don't blindly skip verification in production
curl -k https://example.com

# ✅ Fix the certificate issue or understand why it's happening

Why? -k bypasses security. Use it only for local development.

Mistake 6: Redirects Not Followed

# If a URL redirects, you'll see a 301/302
curl http://github.com
# Returns redirect response

# Follow redirects with -L
curl -L http://github.com
# Returns actual page

Part 9: Quick Reference

Essential Flags

Flag	Purpose	Example
`-X`	HTTP method	`-X POST`
`-H`	Add header	`-H "Content-Type: application/json"`
`-d`	Send data	`-d '{"key":"value"}'`
`-i`	Show response headers	`-i`
`-I`	Only headers (HEAD request)	`-I`
`-s`	Silent (no progress bar)	`-s`
`-o`	Save output to file	`-o response.json`
`-L`	Follow redirects	`-L`
`-u`	Basic auth	`-u user:pass`
`-v`	Verbose (debug mode)	`-v`

Common Patterns

GET request:

curl https://api.example.com/users

GET with headers:

curl -H "Authorization: Bearer TOKEN" https://api.example.com/users

POST JSON:

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "John", "email": "john@example.com"}'

PUT (update):

curl -X PUT https://api.example.com/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name": "Jane"}'

DELETE:

curl -X DELETE https://api.example.com/users/1

Download file:

curl -o image.jpg https://example.com/photo.jpg

Part 10: Next Steps

You now know enough cURL to:

✅ Test any REST API
✅ Debug backend endpoints
✅ Understand HTTP requests and responses
✅ Automate simple tasks

Practice APIs

API	URL	What You Can Do
JSONPlaceholder	jsonplaceholder.typicode.com	Fake REST API for testing
httpbin	httpbin.org	Echo service—see what you sent
GitHub	api.github.com	Real data, public endpoints
wttr.in	wttr.in	Weather in your terminal

Keep Learning

Explore more flags: curl --help or man curl
Try Postman or Insomnia: GUI alternatives to cURL
Learn about API authentication: OAuth, API keys, JWT
Automate with scripts: Combine cURL with bash scripts

Conclusion

cURL is your direct line to any server.

What You Learned	Key Takeaway
What servers are	Client sends request → Server sends response
What cURL is	Command-line tool for HTTP requests
GET requests	Fetch data with `curl URL`
POST requests	Send data with `-X POST -d`
Headers	Use `-H` for Content-Type, Auth, etc.
Debugging	Use `-i` to see headers, `-v` for verbose

Every API you'll ever use speaks HTTP. Now you can speak it too.

Go test your APIs. Happy curling! 🚀

DNS Record Types Explained: A Beginner's Complete Guide

Pratham — Sat, 31 Jan 2026 17:50:45 +0000

The 6 records that make websites, emails, and the internet work.

How does your browser know where google.com lives?

You type a name. Your computer needs an address. Something has to translate between the two.

That something is DNS (Domain Name System)—and it uses different types of records to answer different questions about a domain.

This article covers:

What DNS records are and why they exist
The 6 most important record types: NS, A, AAAA, CNAME, MX, TXT
Real-world analogies that make each record click
How all records work together for one website

Part 1: Why DNS Records Exist

The Problem

A single domain like example.com needs to do many things:

Host a website (where's the web server?)
Receive emails (where's the mail server?)
Prove ownership (how do I verify I own this domain?)
Handle subdomains (what about www, blog, api?)

One domain, many questions. Each question needs a different answer.

The Solution: Different Record Types

Think of DNS like a contact card:

┌─────────────────────────────────────────────────────────────────────────────┐
│                           CONTACT CARD ANALOGY                              │
└─────────────────────────────────────────────────────────────────────────────┘

    DNS Records are like fields on a contact card:

    ┌─────────────────────────────────────────┐
    │  EXAMPLE.COM                            │
    │  ─────────────────────────────────────  │
    │  Office Address:  192.168.1.1    (A)    │  ← Where to visit
    │  Alternate Name:  www → example  (CNAME)│  ← Also known as
    │  Mail Room:       mail.example   (MX)   │  ← Where to send mail
    │  Manager:         ns1.host.com   (NS)   │  ← Who handles inquiries
    │  Notes:           "Verified"     (TXT)  │  ← Extra information
    └─────────────────────────────────────────┘

    Different questions → Different record types!

Part 2: The Big Picture

Before diving into each record, here's how they fit together:

┌─────────────────────────────────────────────────────────────────────────────┐
│                        HOW DNS RECORDS WORK TOGETHER                        │
└─────────────────────────────────────────────────────────────────────────────┘

    User types: example.com
         │
         ▼
    ┌─────────────────┐
    │  DNS RESOLVER   │  "Let me look up this domain..."
    └────────┬────────┘
             │
             │ Checks NS record: "Who manages example.com?"
             ▼
    ┌─────────────────┐
    │  NS RECORD      │ → ns1.dnshost.com (authoritative server)
    └────────┬────────┘
             │
             │ Asks authoritative server for A record
             ▼
    ┌─────────────────┐
    │  A RECORD       │ → 93.184.216.34 (website IP)
    └────────┬────────┘
             │
             ▼
    Browser connects to 93.184.216.34 → Website loads!

    ─────────────────────────────────────────────────────────────

    Meanwhile, for email:

    someone@example.com
         │
         ▼
    ┌─────────────────┐
    │  MX RECORD      │ → mail.example.com (mail server)
    └────────┬────────┘
             │
             ▼
    Email delivered to mail server!

Now let's understand each record type.

Part 3: NS Record — Who's In Charge

The Question It Answers

"Who should I ask for information about this domain?"

The Analogy: Main Office Directory

Imagine you want to know about a company. First, you need to find their main office that handles all inquiries. That's what an NS record does.

NS = Name Server — The server that has the official information about a domain.

Example

example.com.    IN    NS    ns1.dnshost.com.
example.com.    IN    NS    ns2.dnshost.com.

This says: "For any questions about example.com, ask ns1.dnshost.com or ns2.dnshost.com."

Why NS Records Matter

Purpose	Explanation
Delegation	NS records tell the internet who controls a domain
Redundancy	Multiple NS records = backup if one server is down
Domain Transfer	Change NS records to move your domain to a new host

Real-World Use Case

When you buy a domain from GoDaddy but host on Cloudflare:

Before: example.com NS → ns1.godaddy.com
After:  example.com NS → ns1.cloudflare.com

Now Cloudflare controls your domain's DNS!

Part 4: A Record — The Main Address

The Question It Answers

"What's the IPv4 address of this website?"

The Analogy: House Street Address

The A record is like a street address. When someone asks "Where does google.com live?", the A record gives the physical location (IP address).

A = Address — The IPv4 address where the domain points.

Example

google.com.     IN    A    142.250.193.46

This says: "google.com is at IP address 142.250.193.46"

Diagram: How A Records Work

┌─────────────────────────────────────────────────────────────────────────────┐
│                         A RECORD MAPPING                                    │
└─────────────────────────────────────────────────────────────────────────────┘

    Human-readable               Machine-readable
    ┌──────────────┐             ┌────────────────┐
    │ google.com   │ ─── A ────► │ 142.250.193.46 │
    └──────────────┘             └────────────────┘

    ┌──────────────┐             ┌────────────────┐
    │ github.com   │ ─── A ────► │ 140.82.112.4   │
    └──────────────┘             └────────────────┘

    ┌──────────────┐             ┌────────────────┐
    │ example.com  │ ─── A ────► │ 93.184.216.34  │
    └──────────────┘             └────────────────┘

    The browser uses this IP to connect to the server!

Multiple A Records = Load Balancing

Large sites can have multiple A records:

google.com.     IN    A    142.250.193.46
google.com.     IN    A    142.250.193.78
google.com.     IN    A    142.250.80.46

DNS returns different IPs to different users, distributing traffic!

Part 5: AAAA Record — The Modern Address

The Question It Answers

"What's the IPv6 address of this website?"

The Analogy: Same House, New Postal Code Format

Remember IPv4 addresses like 142.250.193.46? We ran out of them.

IPv6 is the new format with virtually unlimited addresses. An AAAA record is like an A record, but for the new system.

AAAA = IPv6 Address (Four A's because IPv6 is 4x longer than IPv4)

Example

google.com.     IN    AAAA    2607:f8b0:4004:800::200e

Why IPv6?

IPv4	IPv6
~4.3 billion addresses	340 undecillion addresses
`142.250.193.46`	`2607:f8b0:4004:800::200e`
Running out	Unlimited for practical purposes

Do You Need AAAA Records?

If Your Site...	AAAA Record?
Is on a modern host	Probably already set up
Needs to reach IPv6-only users	Yes, required
Is internal/small	Optional but good practice

Part 6: CNAME Record — The Nickname

The Question It Answers

"This name is an alias—what's the real name?"

The Analogy: "Also Known As"

Sometimes one name points to another name. Like how "Bill" is an alias for "William."

CNAME = Canonical Name — An alias from one domain name to another.

Example

www.example.com.    IN    CNAME    example.com.
blog.example.com.   IN    CNAME    example.github.io.

www.example.com → "Just use example.com"
blog.example.com → "Actually go to example.github.io"

Diagram: How CNAME Works

┌─────────────────────────────────────────────────────────────────────────────┐
│                        CNAME POINTING TO ANOTHER NAME                       │
└─────────────────────────────────────────────────────────────────────────────┘

    User visits: www.example.com
         │
         ▼
    ┌─────────────────┐
    │  CNAME Record   │  www.example.com → example.com
    └────────┬────────┘
             │ (Follow the alias)
             ▼
    ┌─────────────────┐
    │  A Record       │  example.com → 93.184.216.34
    └────────┬────────┘
             │
             ▼
    Browser connects to 93.184.216.34

    ─────────────────────────────────────────────────────────────

    CNAME is like a redirect: "Don't look here, look THERE"

⚠️ Common Confusion: A vs CNAME

Record Type	Points To	Use When
A	IP address (`142.250.193.46`)	You know the exact IP
CNAME	Another domain name (`example.com`)	You want an alias

Key Rule: CNAME points to a NAME. A record points to an ADDRESS.

Another Rule: You can't use CNAME at the root domain (example.com). Use it only for subdomains (www.example.com, blog.example.com).

When to Use CNAME

Scenario	Use CNAME?
`www.example.com` → `example.com`	✅ Yes
Hosting blog on GitHub Pages	✅ Yes (`blog.example.com` → `user.github.io`)
Root domain to IP	❌ No, use A record

Part 7: MX Record — Email Routing

The Question It Answers

"Where should emails for this domain go?"

The Analogy: Post Office

Imagine your domain is a building. Visitors go to the front door (A record). But mail goes to a separate post office (MX record).

MX = Mail Exchange — The server that handles email for a domain.

Example

example.com.    IN    MX    10    mail.example.com.
example.com.    IN    MX    20    backup-mail.example.com.

The Priority Number

MX    10    mail.example.com.       ← Try this FIRST (lower = higher priority)
MX    20    backup-mail.example.com. ← Try this if first fails

Lower number = Higher priority. Email servers try them in order.

Diagram: Email Routing with MX

┌─────────────────────────────────────────────────────────────────────────────┐
│                        MX RECORD EMAIL ROUTING                              │
└─────────────────────────────────────────────────────────────────────────────┘

    Email sent to: hello@example.com
         │
         ▼
    ┌─────────────────┐
    │ Sender's server │  "Where does example.com receive mail?"
    └────────┬────────┘
             │
             │ Looks up MX record
             ▼
    ┌─────────────────┐
    │  MX Record      │  Priority 10: mail.example.com
    │                 │  Priority 20: backup-mail.example.com
    └────────┬────────┘
             │
             │ Tries mail.example.com first
             ▼
    ┌─────────────────┐
    │  Mail Server    │  Email delivered!
    └─────────────────┘

⚠️ Common Confusion: NS vs MX

Record	Purpose	Controls
NS	Who manages DNS for the domain	DNS queries
MX	Who receives email for the domain	Email delivery

NS is about DNS control. MX is about email delivery.

Real-World MX Setup

Using Gmail for business email:

example.com.    IN    MX    1     ASPMX.L.GOOGLE.COM.
example.com.    IN    MX    5     ALT1.ASPMX.L.GOOGLE.COM.
example.com.    IN    MX    5     ALT2.ASPMX.L.GOOGLE.COM.

Part 8: TXT Record — The Notes Field

The Question It Answers

"What extra information is associated with this domain?"

The Analogy: Sticky Notes

TXT records are like sticky notes attached to your domain. They hold text that proves ownership or provides security information.

TXT = Text — Any text data attached to a domain.

Example

example.com.    IN    TXT    "v=spf1 include:_spf.google.com ~all"
example.com.    IN    TXT    "google-site-verification=abc123xyz"

Common Uses

Use Case	Example TXT Content
Domain Verification	`google-site-verification=abc123`
SPF (Email Security)	`v=spf1 include:_spf.google.com ~all`
DKIM (Email Signing)	`v=DKIM1; k=rsa; p=MIGf...`
DMARC (Email Policy)	`v=DMARC1; p=reject`

Domain Verification Example

When you add a domain to Google Search Console:

Google gives you a code: google-site-verification=abc123xyz
You add a TXT record: example.com TXT "google-site-verification=abc123xyz"
Google checks for this record
Ownership verified!

Why TXT Records Matter for Developers

Service	Uses TXT For
Google Workspace	Domain verification
SSL Certificates	Domain control validation
Email Providers	SPF, DKIM, DMARC
CDN Providers	Ownership proof

Part 9: All Records Working Together

Let's see a complete DNS setup for a small website.

Scenario: Small Business Website

Domain: mybusiness.com
Needs:

Website hosted on a server
www subdomain working
Business email via Google Workspace
SSL certificate verification

Complete DNS Configuration

┌─────────────────────────────────────────────────────────────────────────────┐
│                  COMPLETE DNS SETUP FOR mybusiness.com                      │
└─────────────────────────────────────────────────────────────────────────────┘

Record Type   Name           Value                          Purpose
─────────────────────────────────────────────────────────────────────────────

NS            mybusiness.com ns1.cloudflare.com.            DNS management
NS            mybusiness.com ns2.cloudflare.com.            (backup)

A             mybusiness.com 203.0.113.50                   Website server
AAAA          mybusiness.com 2001:db8::1                    IPv6 for website

CNAME         www            mybusiness.com                 www → root domain
CNAME         blog           mybusiness.github.io           Blog on GitHub

MX            mybusiness.com ASPMX.L.GOOGLE.COM.     (1)    Email via Gmail
MX            mybusiness.com ALT1.ASPMX.L.GOOGLE.COM.(5)    Backup mail

TXT           mybusiness.com "v=spf1 include:_spf.google.." Email security
TXT           mybusiness.com "google-site-verification=..." Ownership proof

Diagram: How They Work Together

┌─────────────────────────────────────────────────────────────────────────────┐
│               ONE DOMAIN, MULTIPLE RECORDS, DIFFERENT PURPOSES              │
└─────────────────────────────────────────────────────────────────────────────┘

                              mybusiness.com
                                    │
          ┌─────────────────────────┼─────────────────────────┐
          │                         │                         │
          ▼                         ▼                         ▼
    ┌───────────┐            ┌───────────┐            ┌───────────┐
    │    NS     │            │   A/AAAA  │            │    MX     │
    │  Records  │            │  Records  │            │  Records  │
    └─────┬─────┘            └─────┬─────┘            └─────┬─────┘
          │                        │                        │
          ▼                        ▼                        ▼
    Cloudflare               Web Server               Gmail Servers
    (controls DNS)           (203.0.113.50)          (handles email)

          │
          ▼
    ┌───────────┐
    │   CNAME   │  www.mybusiness.com → mybusiness.com
    │  Records  │  blog.mybusiness.com → github.io
    └───────────┘

          │
          ▼
    ┌───────────┐
    │    TXT    │  SPF for email security
    │  Records  │  Domain verification
    └───────────┘

Part 10: Quick Reference

Record Types Summary

Record	Purpose	Points To	Example
NS	Who controls DNS	Name server domain	`ns1.cloudflare.com`
A	Website address (IPv4)	IP address	`142.250.193.46`
AAAA	Website address (IPv6)	IPv6 address	`2607:f8b0:...`
CNAME	Alias/redirect	Another domain name	`example.com`
MX	Email server	Mail server domain + priority	`10 mail.google.com`
TXT	Extra info	Any text	`v=spf1 include:...`

When to Use Each Record

I Want To...	Use This Record
Point domain to a server	A (or AAAA for IPv6)
Make www work	CNAME (www → root)
Receive email	MX
Verify domain ownership	TXT
Change DNS provider	NS
Create subdomain alias	CNAME

Quick Commands to Check Records

# Check A record
dig example.com A +short

# Check MX records
dig example.com MX +short

# Check NS records
dig example.com NS +short

# Check TXT records
dig example.com TXT +short

# Check all records
dig example.com ANY +short

Conclusion

DNS records are the backbone of how the internet routes traffic.

Record	One-Line Summary
NS	"Who controls this domain's DNS"
A	"The IPv4 address of this domain"
AAAA	"The IPv6 address of this domain"
CNAME	"This name is an alias for that name"
MX	"Where emails should go"
TXT	"Extra notes attached to the domain"

The key insight: Each record answers a different question. When you understand what question each record answers, DNS stops being mysterious.

Now you can confidently set up and debug DNS for any domain. Go make the internet work! 🌐

How DNS Resolution Works: The Internet's Address Book

Pratham — Sat, 31 Jan 2026 17:44:57 +0000

Prerequisites: Basic familiarity with the command line (optional but helpful).
Audience: Developers who know that DNS works, but not how it works.

The Great Human-Computer Disconnect

Here is the fundamental problem of the internet:

Humans remember names. (google.com, hashnode.com, twitter.com)
Computers only know numbers. (142.250.193.206, 104.22.4.1)

If you want to visit Google, you type google.com. But your browser has no idea where that is. It needs the IP address.

This bridging of the gap—turning a human name into a computer address—is called DNS Resolution (Domain Name System).

Most tutorials describe DNS as "The Phonebook of the Internet."
You look up a name, you find a number. Simple, right?

Wrong.

That analogy is too simple. A phonebook is a single book with every number in the world. If DNS worked like that, it would be a file with billions of lines that every computer would have to download every day. It would be impossible to maintain.

The Reality: DNS is not a Phonebook. DNS is a distributed Hierarchy.

It’s more like a Global Corporate Bureaucracy. No single person knows everyone's number. But everyone knows who to ask next.

Today, we are going to manually perform the job of your browser. We are going to trace a request step-by-step across the world to find out exactly how google.com becomes an IP address.

The Tool: Meet `dig`

To see this invisible conversation, we need a tool. We will use dig (Domain Information Groper).

Think of dig as an X-Ray machine for DNS. It lets us ask the questions your computer asks silently in the background.

Open your terminal (Git Bash or Mac/Linux Terminal) and type:

dig google.com

You'll get a big scary block of text. Don't panic. We are going to ignore the auto-magic and do it manually, layer by layer.

The Tree Principle: Understanding the Hierarchy

DNS is structured like an upside-down tree.

┌─────────────────────────────────────────────────────────────────────────────┐
│                          DNS HIERARCHY PYRAMID                              │
└─────────────────────────────────────────────────────────────────────────────┘

                              ┌─────────────┐
                              │    ROOT     │  ← "." (the invisible dot)
                              │   SERVERS   │     13 clusters worldwide
                              └──────┬──────┘
                                     │
                    ┌────────────────┼────────────────┐
                    │                │                │
                    ▼                ▼                ▼
            ┌─────────────┐  ┌─────────────┐  ┌─────────────┐
            │    .com     │  │    .org     │  │    .net     │
            │    TLD      │  │    TLD      │  │    TLD      │  ← Top-Level Domain
            └──────┬──────┘  └─────────────┘  └─────────────┘
                   │
      ┌────────────┼────────────┐
      │            │            │
      ▼            ▼            ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ google   │ │ amazon   │ │ github   │  ← Authoritative servers
│ .com     │ │ .com     │ │ .com     │     (owned by each company)
└──────────┘ └──────────┘ └──────────┘

Do you notice something weird?
Technically, when you type google.com, you are actually typing:

google.com. (Notice the dot at the end!)

That hidden dot at the end represents the Root. That is where our journey begins.

The Walkthrough: Resolving `google.com` Manually

Imagine we are a "Recursive Resolver" (like the server at your ISP). We know NOTHING except where the Root is.
Our mission: Find the IP of google.com.

Step 1: Asking the Wise Elders (The Root Servers)

We don't know where google.com is. But we know where the Root Servers (.) are. These are the 13 logical servers that oversee the entire internet.

Let's ask them: "Hey, do you know where google.com is?"

dig . NS

. = The Root
NS = Name Server (Who is the boss here?)

The Answer:
The Root servers will tell you: "I don't know who 'google' is. But I know who manages all the .com websites. Go talk to the .com servers."

Step 2: Asking the Middle Managers (The TLD Servers)

Okay, we have a lead. We need to talk to the servers that manage .com. These are called Top Level Domain (TLD) Servers.

Let's ask them: "Hey .com servers, do you know where google.com is?"

dig com. NS

The Answer:
The .com servers (run by a company called Verisign) will say: "I don't know the specific IP for Google. I have millions of dot-coms! But, I have the address of Google's specific Name Servers. Go talk to them."

They hand us the address of ns1.google.com.

Step 3: Asking the Owner (Authoritative Name Servers)

Now we are getting close. We have been directed to Google's own personal name servers. These are the Authoritative Name Servers. They are the final authority on everything inside the Google empire.

Let's ask them: "Hey Google Name Server, surely YOU know where google.com is?"

dig google.com. NS

The Answer:
Google's server says: "Yes, I am the boss of Google.com. What do you want?"

Step 4: The Final Question (The A Record)

Now that we have the boss on the line, we ask for the actual address.

"I want the Address (A Record) for google.com."

dig @ns1.google.com google.com A

(Note: roughly simulating the request to the specific nameserver)

The Answer:

google.com.    300    IN    A    142.250.193.206

BOOM. We found it. 142.250.193.206.

Diagram: dig Commands Mapped to DNS Stages

┌─────────────────────────────────────────────────────────────────────────────┐
│                  dig COMMANDS ↔ DNS LOOKUP STAGES                           │
└─────────────────────────────────────────────────────────────────────────────┘

    DNS HIERARCHY                           dig COMMAND
    ─────────────                          ─────────────

         ROOT (.)                          dig . NS
            │                              └─► Returns: a.root-servers.net
            │
            ▼
         TLD (.com)                        dig com NS
            │                              └─► Returns: a.gtld-servers.net
            │
            ▼
      AUTHORITATIVE                        dig google.com NS
       (google.com)                        └─► Returns: ns1.google.com
            │
            │
            ▼
       FINAL ANSWER                        dig google.com
       (IP Address)                        └─► Returns: 142.250.193.46

4. The Full Flow Visualization

Let's recap what just happened. This is the Resolver Dance:

┌─────────────────────────────────────────────────────────────────────────────┐
│              COMPLETE DNS RESOLUTION FLOW FOR google.com                    │
└─────────────────────────────────────────────────────────────────────────────┘

  YOU                 RECURSIVE              ROOT           TLD          GOOGLE
(Browser)             RESOLVER              SERVERS       (.com)         (Auth)
   │                     │                     │             │              │
   │ "google.com?"       │                     │             │              │
   │────────────────────►│                     │             │              │
   │                     │                     │             │              │
   │                     │ "Who has .com?"     │             │              │
   │                     │────────────────────►│             │              │
   │                     │                     │             │              │
   │                     │ "Ask a.gtld-servers.net"          │              │
   │                     │◄────────────────────│             │              │
   │                     │                     │             │              │
   │                     │ "Who has google.com?"             │              │
   │                     │──────────────────────────────────►│              │
   │                     │                                   │              │
   │                     │ "Ask ns1.google.com"              │              │
   │                     │◄──────────────────────────────────│              │
   │                     │                                   │              │
   │                     │ "What's the IP of google.com?"               │   │
   │                     │─────────────────────────────────────────────────►│
   │                     │                                                  │
   │                     │ "142.250.193.46"                                 │
   │                     │◄─────────────────────────────────────────────────│
   │                     │                                                  │
   │ "142.250.193.46"    │                                                  │
   │◄────────────────────│                                                  │
   │                     │                                                  │

   TOTAL: 4 queries behind the scenes for 1 domain lookup!

Why don't we see this every time?

If your browser did this Recursion (asking step-by-step) for every single image and file, the internet would be painfully slow.

This is why we have Caching.

Your Browser caches the IP for a few minutes.
Your OS (Windows/Mac) caches it.
Your Router caches it.
Your ISP caches it.

When you type google.com, your computer likely remembers the answer from 5 minutes ago and skips the entire journey. You only see this "dance" when the cache expires (TTL - Time To Live).

Summary

Next time you see a "DNS Resolution Error" in Chrome, you know exactly what failed.

It means your computer shouted into the void, asked the Root, asked the TLD, or asked the Authoritative server... and somewhere along that chain, nobody answered.

We typically treat dig and DNS as boring settings to configure. But under the hood, it's a beautifully organized, decentralized relay race that keeps the internet human-friendly.

Glossary for the Road:

Root (.): The start of the hierarchy.
TLD (.com, .org): The category managers.
Authoritative Server: The owner who knows the final answer.
Recursive Resolver: The servant (ISP) that runs around asking these questions for you.
A Record: The IPv4 Address (The destination).
NS Record: Name Server (Who manages this zone?).

Network Devices Explained: Unboxing the Internet

Pratham — Sat, 31 Jan 2026 17:33:36 +0000

Prerequisites: None. Just curiosity.
Audience: Developers who treat the network as a "black box" and want to know what actually happens when they plug in that Ethernet cable.

The Invisible City

Imagine you’re standing on the roof of a massive skyscraper, looking down at a sprawling metropolis. Millions of cars, trucks, and delivery bikes are weaving through thousands of intersections, merging onto highways, and stopping at checkpoints.

Every single vehicle knows exactly where it’s going.
Every traffic light coordinates perfectly.
Every package gets delivered to the right desk on the right floor of the right building.

That is the Internet.

But for most of us—even software engineers—the internet works more like "Magic." We plug a cable into the wall, and suddenly we’re watching Netflix or pushing code to GitHub. We rarely stop to think about the physical machinery making that happen.

We treat the network like a black box:
Request goes in → Response comes out.

But what happens inside that box? What are the specialized machines handling your data at every step?

Today, we are going to unbox the internet. We’ll break down the specific roles of the Modem, Router, Switch, Firewall, and Load Balancer.

We won't just list definitions. We’ll look at the problem each device solves, the analogy that makes it stick, and the reality of how it works in production.

1. The Modem: The Translator

The Problem: The Language Barrier

Your computer is a digital creature. It speaks in Binary (0s and 1s). It understands electricity being "ON" or "OFF."

The Internet Service Provider (ISP) that brings the internet to your house, however, usually travels over telephone lines, coaxial cables, or fiber optics. These cables don’t carry "0s and 1s" directly; they carry Analog Signals (continuous waves of electricity, light, or radio frequencies).

Here lies the problem:
Your computer (Digital) cannot understand the signal coming from the wall (Analog).

If you plugged the raw internet cable directly into your laptop, your computer would hear meaningless static noise. It needs a translator.

The Solution: MO-dem

Enter the Modem. Its name literally explains its job:

MOdulator: Takes digital signals from your computer/router and converts them into analog waves to send out.
DEModulator: Takes analog waves coming from the ISP and converts them back into digital signals your computer can read.

Analogy: The Translator at the Border
Imagine you are an English speaker (Your Computer) trying to call a friend in Japan. But the phone line only transmits Japanese (ISP Signal).
The Modem is the translator sitting on the line. You speak English → They translate to Japanese for the line. The friend replies in Japanese → They translate back to English for you.

Diagram: The Bridge

      OUTSIDE WORLD (ISP)                    YOUR HOME (Local Network)
      ~~~~~~~~~~~~~~~~~~~                    =========================

      [ Analog Signals ]                     [ Digital Signals (0/1) ]
         (Waves/Light)                                (Binary)
              │                                          │
              ▼                                          ▼
      ┌──────────────────────────────────────────────────────────┐
      │                        THE MODEM                         │
      │   (Translates Analog <-> Digital)                        │
      └──────────────────────────────────────────────────────────┘
              ▲                                          ▲
              │                                          │
Public IP: 98.45.12.1                           (To Router/PC)

Key Takeaway: The Modem creates the connection to the internet. Without it, you have a local network that can’t talk to the outside world.

2. The Router: The Traffic Controller

The Problem: One Connection, Many Devices

So, you have a Modem. It successfully connects you to the internet.

But the ISP usually gives the Modem just one Public IP Address (like 98.45.12.1). Think of this as your "Home Relationship Address."

Now, you have a problem.
You have a Laptop, a Phone, a Smart TV, and a Tablet.
You have 4 devices, but only 1 IP address.

Who gets it? If the TV takes the IP to stream Netflix, does your laptop lose internet?

The Solution: The Router (Network Address Translation)

The Router solves this by creating a private network inside your house.

It assigns internal IDs (Private IPs, usually 192.168.x.x) to your devices.
It acts as the Gateway. When your Laptop wants to request Google.com:
- Laptop sends request to Router.
- Router notes down: "Laptop asked for Google."
- Router switches the "Create Address" to the Public IP (The Modem's IP) and sends it out.
- When Google replies, the Router checks its note: "Ah, this reply is for the Laptop."
- Router forwards data to Laptop.

This process is called NAT (Network Address Translation).

Analogy: The Mailroom
Imagine a massive office building. The building has one postal address (123 Tech Street) -- this is your Public IP.
Inside, there are 500 employees. The Postman brings all the mail to the huge reception desk (The Router).
The Router reads "Attention: Alice, Desk 4B" and internally directs the letter to Alice.
Alice doesn't need her own separate street address; she just needs the Mailroom to route traffic to her.

Diagram: WAN vs LAN

      INTERNET
         │
         ▼
    [ Public IP ]  (98.45.12.1)
  ┌───────────────┐
  │    ROUTER     │ <--- The Gateway
  └───────┬───────┘
          │
    [ Private IPs ] (192.168.1.x)
          │
  ┌───────┼───────────────┐
  ▼       ▼               ▼
Laptop   Phone          Smart TV
(.1.2)   (.1.3)         (.1.4)

Key Takeaway: The Router directs traffic. It allows multiple devices to share one internet connection.

3. The Local Floor: Hub vs Switch

Now let's zoom inside the local network. How do devices talk to the router, or to each other (like your phone casting video to your TV)?

This happens at Layer 2 (Data Link Layer), and there are two ways to do it: the dumb way (Hub) and the smart way (Switch).

The Hub: The "Blind Shouter" (Obsolete)

A Hub is a simple connecting box. You plug computers A, B, and C into it.
When Computer A wants to send a private file to Computer B:

Computer A sends signal to the Hub.
The Hub has no brain. It blindly copies that signal and sends it to EVERY port.
Computer B receives it (Good!).
Computer C, D, and E also receive it (Bad!). They have to check the message, realize "This isn't for me," and ignore it.

Analogy: Shouting in a Room
You want to tell Piyush a secret. Instead of walking over to him, you stand in the middle of the office and SCREAM the secret.
Piyush hears it. But so does Hitesh, Anirudh, and everyone else.
It’s insecure (everyone hears) and inefficient (if everyone shouts at once, nobody can hear anything—this is called a "Collision").

The Switch: The "Smart Whisperer" (Modern)

A Switch looks like a Hub, but it has a brain. It keeps a memory table called a MAC Address Table.

When you first plug in Computer A (Port 1) and Computer B (Port 2):

The Switch learns: "Okay, MAC Address AA:11 is on Port 1. MAC Address BB:22 is on Port 2."
Now, when Computer A sends a file to Computer B:
The Switch looks at the destination.
It opens a direct, private electrical path from Port 1 to Port 2.
It sends the data only to Port 2. Computer C never sees it.

Analogy: The Switchboard Operator
You pick up the phone and ask for Piyush. The operator (Switch) plugs your wire directly into Piyush's wire. You have a private conversation. No one else’s phone rings.

Diagram: Broadcast vs Unicast

       THE HUB (DUMB)                       THE SWITCH (SMART)
      (Data for Device B)                  (Data for Device B)

         [Incoming]                           [Incoming]
             │                                    │
       ┌─────▼─────┐                        ┌─────▼─────┐
       │   BOOM!   │                        │   Table   │ Lookups
       └─┬───┬───┬─┘                        └───┬───────┘
         │   │   │                              │ (Direct Path)
    ┌────▼─┐ │ ┌─▼────┐                    ┌────X─┐   ┌───────┐
    │Dev A │ │ │Dev C │                    │Dev A │   │Dev C │
    │(No!) │ │ │(No!) │                    │(No!) │   │(No!) │
    └──────┘ │ └──────┘                    └──────┘   └──────┘
             │                                    │
             ▼                                    ▼
          Dev B                                Dev B
         (YES!)                               (YES!)

Key Takeaway:

Hub: Shouts to everyone. Slow, insecure, obsolete.
Switch: Whispers to the target. Fast, secure, standard.

4. The Firewall: The Bouncer

The Problem: The Open Door Policy

Now your Router is directing traffic beautifully. But there's a risk.
Connecting to the internet is like opening your front door to the entire world.
Most guests are welcome (Requested web pages, Netflix streams).
But some are not (Hackers, bots, malware).

If you have a server running on your network (like a database), you don't want just anyone to be able to talk to it.

The Solution: The Firewall

A Firewall sits between your internal network and the outside world. It enforces a strict set of rules about who gets in and who gets out.

It inspects every single packet of data and asks:

Where are you coming from? (Source IP)
Where are you going? (Destination Port)
Are you on the list? (Rule Set)

Analogy: The Club Bouncer
The Firewall is the Bouncer at the club entrance.
Rule: "Employees only."
Scenario: A random stranger tries to walk in.
Action: Bouncer blocks them. "You're not on the list."
Scenario: The Manager walks in.
Action: Bouncer opens the rope. "Go right ahead."

In technical terms:

Allow traffic on Port 80 (Websites).
Block traffic on Port 22 (SSH/Remote Control) from unknown IPs.

Diagram: The Wall

      INTERNET (The Wild West)
                 │
                 ▼
       ┌─────────────────────┐
       │     THE FIREWALL    │
       │  [ Rules: ]         │
       │  [ 1. Allow HTTP    │
       │  [ 2. Allow Netflix │
       │  [ 3. BLOCK ALL ELSE│
       └─────────────────────┘
                 │
                 ▼
        Internal Network (Safe)

Key Takeaway: The Firewall filters traffic. It decides what is allowed to pass based on security rules.

5. The Load Balancer: The Scalability Hero

The Problem: Too Popular for Your Own Good

This one is crucial for backend engineers.
Imagine you built a web app. It lives on Server A.
Suddenly, your app goes viral. You have 1,000,000 users trying to access Server A at the same time.

Server A crashes. It catches fire. It dies.
You buy a second server, Server B, to help. But how do you tell half the users to go to A and half to go to B? The users only know one address (your website URL).

The Solution: The Load Balancer

A Load Balancer stands in front of your servers. It acts as the "Face" of your application.

All 1,000,000 requests hit the Load Balancer first.
The Load Balancer looks at the servers behind it.
It distributes the work evenly.
- Request 1 → Server A
- Request 2 → Server B
- Request 3 → Server A
- ...

If Server A crashes? The Load Balancer notices, stops sending traffic there, and sends everything to Server B until A is fixed. This is called Health Checking.

Analogy: The Traffic Cop (or Bank Teller Queue)
You walk into a bank. There are 5 tellers (Servers).
You don't just wander to a random desk. You wait in a single line.
A person (Load Balancer) says "Next! Go to Counter 3." "Next! Go to Counter 1."
If Counter 2 goes on lunch break (Crashes), they stop sending people to Counter 2.

Diagram: Distributing the Load

              Traffic (1M Users)
                     │
                     ▼
           ┌───────────────────┐
           │   LOAD BALANCER   │ <--- Public IP
           └───────┬───┬───────┘
                   │   │
           ┌───────┘   └───────┐
           ▼                   ▼
    ┌─────────────┐     ┌─────────────┐
    │ Web Server A│     │ Web Server B│
    └─────────────┘     └─────────────┘

Key Takeaway: The Load Balancer distributes traffic. It ensures reliability and prevents any single server from being overwhelmed.

6. The Grand Orchestration: Putting It All Together

So, how does the internet utilize all of these at once?
Let's trace a request from your Laptop to a Website (like Hashnode).

The Journey of a Packet

You (Laptop): Type hashnode.com and hit Enter.
Switch/Router: Your local router sends the request out through the Modem (translating Digital → Analog).
The Journey: Signals travel across the world (Fiber optics, undersea cables).
Destination Firewalls: The request hits Hashnode's data center guard. Firewall checks: "Is this port 80/443 (Web traffic)? Yes. Allowed."
Load Balancer: The request hits Hashnode's Load Balancer. It sees their main server is busy, so it routes you to Server #42.
Switch: Inside the data center rack, a high-speed Switch directs the packet into the exact cable for Server #42.
Server: Server #42 processes your request and sends the website back.

The Full Stack Architecture

[ USER'S HOME ]                             [ THE CLOUD / DATA CENTER ]
                                       (Your Startup's Infrastructure)

Laptop                                            ┌─────────────┐
  │                                           ┌──►│ App Server 1│
  ▼                                           │   └─────────────┘
Router (Gateway)                              │
  │                                     ┌─────┴───────┐
  ▼                                     │Load Balancer│
Modem (Translator)                      └─────┬───────┘
  │                                           ▲
  │ (The Internet)                            │
  └───────────────────────────────────────────┘
               Fiber/Cables                   │
                                        ┌─────┴────┐
                                        │ Firewall │ (Security Gate)
                                        └──────────┘

Why This Matters for Developers

You might be asking: "I write JavaScript/Python. Why do I care about cables and boxes?"

Troubleshooting: When your app "isn't working," knowing where it stopped is 90% of the battle.
- "Can I ping the server?" (Network is up).
- "Is the port blocked?" (Firewall issue).
- "Is one server overloaded?" (Load Balancer configuration).
Latency: Every "hop" (device) adds time. Understanding that your request goes through 10+ switches and routers helps you design faster systems (e.g., using CDNs to get closer to the user).
Security: As a backend dev, you will configure "Security Groups" in AWS/Cloud. That is literally just configuring a virtual Firewall.

Conclusion

The internet isn't magic. It's a relay race passed between very specialized machines.

Modem: The Translator (Analog ↔ Digital).
Router: The Traffic Controller (1 Public IP → Many Private IPs).
Switch: The Whisperer (Direct device-to-device talk).
Firewall: The Bouncer (Security rules).
Load Balancer: The Scalability Hero (Distributes work).

Next time you lose internet, don't just accept it. Look at the lights.
Is the Modem connecting? Is the Router broadcasting?
Unbox the black box.

Found this helpful? I write about unboxing complex tech concepts every week. Follow for more!

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

Pratham — Sat, 31 Jan 2026 17:27:03 +0000

You've used git commit hundreds of times. But do you know what actually happens when you run it?

Most developers treat Git like a black box—type the magic spell, hope for the best. When something goes wrong (detached HEAD, lost commits, merge nightmares), they panic because they don't understand the mechanics.

This article changes that.

After reading this, you'll see Git not as a mysterious version control system, but as what it really is: a simple key-value database with some clever pointers on top.

What you'll learn:

What the .git folder actually contains (and why deleting it erases everything)
How Git stores your files (Blobs, Trees, Commits)
What really happens during git add and git commit
Why branches are "free" and commits are permanent
How to explore Git's internals yourself

Part 1: The .git Folder — Where Everything Lives

When you run git init or git clone, Git creates a hidden folder called .git in your project root. This folder IS your repository.

my-project/
├── src/
├── package.json
├── README.md
└── .git/           ← This IS the repository. Everything else is just "the current version"

[!IMPORTANT]
Delete .git = Delete all history. The project files remain, but every commit, every branch, every bit of version control is gone. The .git folder is not a cache or backup—it IS Git.

What's Inside .git?

# Run this in any Git repository
ls -la .git/

# Output:
.git/
├── HEAD                 ← "You Are Here" marker
├── config               ← Repository settings (remotes, user info)
├── description          ← Used by GitWeb (you can ignore this)
├── hooks/               ← Scripts that run on events (commit, push, etc.)
├── index                ← The Staging Area (binary file)
├── logs/                ← History of where HEAD and refs have been (reflog)
├── objects/             ← THE DATABASE: All your files, folders, and commits
├── refs/                ← Branch and tag pointers
│   ├── heads/           ← Local branches (each is a text file!)
│   └── tags/            ← Tags
└── packed-refs          ← Optimization: compressed refs for large repos

The Big Three you need to understand:

objects/ — The database storing all content
refs/ — The labels (branches, tags) pointing to commits
HEAD — The pointer saying "you are currently here"

Everything else is configuration or optimization. Master these three, and you master Git.

Part 2: Git Objects — The Building Blocks

Git stores everything as objects in the .git/objects/ directory. There are only three types you need to know:

Object Type	What It Stores	Analogy
Blob	File content (just the bytes)	A page of text
Tree	Directory structure (list of blobs and other trees)	A table of contents
Commit	Snapshot metadata (points to a tree + parent + message)	A chapter in a book

Why Only Three?

This is Git's genius: by breaking everything into these three primitives, Git can:

Deduplicate identical content automatically
Verify integrity with cryptographic hashes
Build any structure from simple building blocks

2.1 Blobs: The Content Store

A blob (Binary Large Object) stores the raw content of a file—nothing else. No filename. No permissions. Just bytes.

Example: You create a file called hello.txt with content Hello, World!

Git doesn't store:

filename: hello.txt
content: Hello, World!

Git stores ONLY:

blob: Hello, World!

Why no filename? Because the filename is metadata, stored separately in the Tree. This allows Git to detect when you rename a file—the blob stays the same, only the Tree changes.

The SHA-1 Hash (Content Address)

Every object gets a unique 40-character ID based on its content:

echo "Hello, World!" | git hash-object --stdin
# Output: 8ab686eafeb1f44702738c8b0f24f2567c36da6d

This hash IS the address. Git stores the blob at:

.git/objects/8a/b686eafeb1f44702738c8b0f24f2567c36da6d
              ↑↑
              First 2 characters = directory name

[!NOTE]
Why hashing matters: If anyone changes even one byte of your file, the hash changes completely. Git uses this to guarantee data integrity—if the hash matches, the content is exactly what was saved.

Same Content = Same Blob

Create two files with identical content:

echo "Hello, World!" > file1.txt
echo "Hello, World!" > file2.txt

Git creates only ONE blob. Both files point to the same 8ab686e... object. This is how Git saves space—duplicates are free.

2.2 Trees: The Directory Structure

A tree is like a directory listing. It contains:

Pointers to blobs (files)
Pointers to other trees (subdirectories)
Filenames and permissions

Example Tree:

100644 blob 8ab686ea... hello.txt
100644 blob 2b7e1f5c... style.css
040000 tree 5d3c8f2a... src/

Entry	Meaning
`100644`	File permissions (normal file)
`blob`	Object type
`8ab686ea...`	SHA-1 hash of the blob
`hello.txt`	Filename

Why this structure?

Filenames live HERE, not in blobs
Renaming a file = new tree, same blob (efficient!)
Subdirectories are just nested trees

Diagram: Tree → Blob Relationship

                         Tree (root directory)
                         ┌──────────────────────────────────────┐
                         │ 100644 blob abc123  index.html       │
                         │ 100644 blob def456  style.css        │
                         │ 040000 tree 789abc  src/             │
                         └──────────────────────────────────────┘
                                        │
                              ┌─────────┴─────────┐
                              ▼                   ▼
                    Blob (abc123)           Tree (789abc)
                    ┌────────────┐          ┌─────────────────────┐
                    │ <html>     │          │ 100644 blob aaa111  │
                    │ <head>     │          │   app.js            │
                    │ ...        │          │ 100644 blob bbb222  │
                    └────────────┘          │   utils.js          │
                                            └─────────────────────┘

2.3 Commits: Snapshots in Time

A commit is the glue that holds everything together. It contains:

Field	What It Is
`tree`	Pointer to the root tree (the project snapshot)
`parent`	Pointer to the previous commit (or none for first commit)
`author`	Who wrote the code + timestamp
`committer`	Who made the commit + timestamp
`message`	Your commit message

Example Commit Object:

tree 5d3c8f2a4b1e0f3d2c1a0b9e8d7c6f5a4b3c2d1e
parent 7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b
author Piyush <piyush@example.com> 1706712000 +0530
committer Piyush <piyush@example.com> 1706712000 +0530

feat: add user login functionality

Why parent matters:

Creates a linked list of history
Each commit knows what came before it
Commits only look BACKWARD, never forward

The Time Travel Analogy

Imagine Git history as a timeline:

You are in 2024 (the latest commit)
You time travel back to 1990 (an older commit)
You decide to stay in 1990 and create a new commit

This new commit branches off from 1990. It doesn't connect to 2024 because, in this new timeline, 2024 hasn't happened yet. If the new commit automatically referenced the "future" commit, it would create a loop rather than a history.

This is why detached commits are orphaned: They're on an alternate timeline that doesn't connect to the main branch.

Diagram: The Complete Object Relationship

┌─────────────────────────────────────────────────────────────────────────────┐
│                           COMPLETE OBJECT RELATIONSHIP                      │
└─────────────────────────────────────────────────────────────────────────────┘

    Commit (abc123)                    Commit (def456)
    ┌──────────────────────┐           ┌──────────────────────┐
    │ tree: 111aaa         │           │ tree: 222bbb         │
    │ parent: def456   ────┼──────────►│ parent: (none)       │
    │ author: Piyush       │           │ author: Piyush       │
    │ message: "Add login" │           │ message: "Initial"   │
    └──────────────────────┘           └──────────────────────┘
              │                                  │
              ▼                                  ▼
        Tree (111aaa)                      Tree (222bbb)
        ┌─────────────┐                    ┌─────────────┐
        │ login.html  │                    │ index.html  │
        │ style.css   │                    │ README.md   │
        │ src/        │                    └─────────────┘
        └─────────────┘                           │
              │                                   ▼
              ▼                            Blobs (files)
        Blobs (files)

    Each commit is a COMPLETE SNAPSHOT, not a diff!
    Git calculates diffs on-the-fly by comparing trees.

[!NOTE]
Commits are snapshots, not diffs. Git doesn't store "what changed." It stores the entire tree at that point. Diffs are calculated when you ask for them by comparing two commits.

Part 3: What Happens During `git add`

Now that you understand the building blocks, let's trace what happens when you run git add.

The Three Areas

┌─────────────────┐      ┌─────────────────┐      ┌─────────────────┐
│  WORKING DIR    │      │  STAGING AREA   │      │   REPOSITORY    │
│                 │ git  │    (Index)      │ git  │   (.git/objects)│
│  Your files     │ add  │ .git/index      │commit│                 │
│  on disk        │─────►│                 │─────►│  Permanent      │
│                 │      │  "Ready to      │      │  history        │
│                 │      │   commit"       │      │                 │
└─────────────────┘      └─────────────────┘      └─────────────────┘

Step-by-Step: What `git add src/login.js` Does

1. Hash the file content

# Git calculates the SHA-1 hash of the file
sha1("content of login.js") = 8ab686eafeb1f...

2. Create a blob object

# If this hash doesn't exist yet, Git creates the blob:
.git/objects/8a/b686eafeb1f44702738c8b0f24f2567c36da6d

3. Update the index (staging area)

# Git updates .git/index with:
# "When you commit, include: src/login.js → blob 8ab686e..."

Verify It Yourself

# Create a file
echo "console.log('Hello');" > test.js

# Stage it
git add test.js

# See what's in the staging area
git ls-files --stage
# Output: 100644 a1b2c3d4e5f6... 0    test.js
#         ↑       ↑              ↑    ↑
#       perms    blob hash    stage  filename

# The blob now exists in .git/objects/
find .git/objects -type f
# You'll see: .git/objects/a1/b2c3d4e5f6...

Key insight: git add doesn't just "stage" a file—it creates the blob object immediately. The staging area is a list of "blobs I want to commit."

Part 4: What Happens During `git commit`

When you run git commit, Git does three things:

Step 1: Create Tree Object(s)

Git reads the staging area (.git/index) and creates tree objects representing the directory structure.

Index says:
  - src/login.js → blob 8ab686e
  - src/auth.js  → blob 4d5e6f0
  - style.css    → blob 2b7e1f5

Git creates:
  - Tree for src/ (pointing to login.js and auth.js blobs)
  - Tree for root (pointing to src/ tree and style.css blob)

Step 2: Create Commit Object

Git creates a commit containing:

Pointer to the root tree
Pointer to the current HEAD commit (parent)
Your author info and message

# The new commit object:
tree 5d3c8f2a4b...
parent 7a8b9c0d1e...  ← Current HEAD becomes parent
author Piyush <...>
message: feat: add login

Step 3: Update the Branch Pointer

# Before commit:
.git/refs/heads/main → 7a8b9c0d1e...

# After commit:
.git/refs/heads/main → abc123def4...  ← Updated to new commit!

That's it. The branch file is just updated with the new commit's hash.

Diagram: The Complete Flow

┌─────────────────────────────────────────────────────────────────────────────┐
│                        git add → git commit FLOW                            │
└─────────────────────────────────────────────────────────────────────────────┘

  WORKING DIRECTORY              STAGING AREA                REPOSITORY
  ┌─────────────────┐           ┌─────────────┐           ┌─────────────────┐
  │                 │           │             │           │                 │
  │  login.js  ─────┼── add ───►│ login.js    │           │  objects/       │
  │  (modified)     │           │ (blob hash) │           │   ├── blobs     │
  │                 │           │             │── commit─►│   ├── trees     │
  │  style.css ─────┼── add ───►│ style.css   │           │   └── commits   │
  │  (modified)     │           │ (blob hash) │           │                 │
  │                 │           │             │           │  refs/heads/    │
  └─────────────────┘           └─────────────┘           │   └── main ─────┼─┐
                                                          │     (updated)   │ │
                                                          └─────────────────┘ │
                                                                    ▲         │
                                                                    │         │
                                                                    └─────────┘
                                                                  Points to new
                                                                  commit hash

Part 5: Refs and HEAD — The Label System

Branches Are Just Text Files

This is the most liberating Git insight: a branch is literally a text file containing a 40-character hash.

# See what 'main' branch points to:
cat .git/refs/heads/main
# Output: abc123def456789...

# That's it. That's the entire branch.

Why this matters:

Creating a branch is instant (just create a tiny file)
Deleting a branch doesn't delete commits
"Merging" is just moving pointers

HEAD: The "You Are Here" Marker

HEAD tells Git where you currently are. It usually points to a branch:

cat .git/HEAD
# Output: ref: refs/heads/main

This means: "I'm on the main branch."

Normal vs Detached HEAD

State	HEAD Contains	What Happens on Commit
Normal	`ref: refs/heads/main`	Branch moves forward with you
Detached	`abc123def456...` (raw hash)	No branch moves; commit is orphaned

Normal State:

HEAD → refs/heads/main → Commit C
                              ↑
                         You commit D
                              ↓
HEAD → refs/heads/main → Commit D

Detached State:

HEAD → Commit B (directly)
            ↑
       You commit D
            ↓
HEAD → Commit D

But 'main' still points to Commit C!
D has no branch. It's an orphan.

[!CAUTION]
Detached HEAD warning: If you commit in detached HEAD state, your work is at risk. Always create a branch (git checkout -b new-branch) before committing if you're detached.

What Counts as a "Reference"?

Reference Type	Example	Stable?
Branch name	`main`, `feature-x`	✅ Yes
Tag	`v1.0.0`	✅ Yes
HEAD (on a branch)	`HEAD` → `main` → commit	✅ Yes
Detached HEAD	`HEAD` → commit directly	❌ Only while you're there!

The moment you leave a detached commit, it becomes eligible for garbage collection.

Reachability: Why Some Commits Survive

Git's garbage collector deletes objects with zero references. But it checks reachability:

main → C → B → A (all reachable from main)
           ↑
           └─ D (orphan - no branch points here)

Garbage collector:
✓ A is reachable from main (through C → B → A)
✓ B is reachable from main (through C → B)
✓ C is reachable from main (directly)
✗ D is NOT reachable - will be deleted

The Chain of Custody: As long as a branch points to the tip, all ancestor commits are protected because Git follows parent pointers.

The Mountain Climbers Analogy

Imagine a team of mountain climbers roped together:

The Helicopter (Branch) is holding the top climber (C)
Climber C is holding the rope for Climber B
Climber B is holding the rope for Climber A

Even though the helicopter only holds C, climbers A and B don't fall because they're chained to C.

Your detached commit D is a climber who tied their rope to B, but B isn't holding onto D. If the helicopter (branch) doesn't come down to pick up D specifically, D falls.

Key insight: Parent pointers only go backward. B doesn't know D exists.

Part 6: Hands-On Exploration

Commands to Inspect Git Objects

# See what type an object is
git cat-file -t abc123
# Output: commit, tree, or blob

# See the content of an object
git cat-file -p abc123
# Output: The actual content

Example: Trace a Commit to Its Files

# 1. Get the latest commit hash
git rev-parse HEAD
# Output: abc123def456...

# 2. See the commit object
git cat-file -p abc123
# Output:
# tree 111aaa222bbb...
# parent 333ccc444ddd...
# author Piyush <...>
# ... message ...

# 3. See the tree (directory snapshot)
git cat-file -p 111aaa
# Output:
# 100644 blob 555eee666fff    login.html
# 100644 blob 777ggg888hhh    style.css
# 040000 tree 999iii000jjj    src

# 4. See a blob (file content)
git cat-file -p 555eee
# Output: The actual HTML content!

The Reflog: Your Safety Net

Even if you lose a commit, Git remembers where HEAD has been:

git reflog
# Output:
# abc123 HEAD@{0}: commit: feat: add login
# def456 HEAD@{1}: checkout: moving from main to feature
# 789abc HEAD@{2}: commit: fix: typo

Recover a lost commit:

# Find it in reflog
git reflog

# Create a branch to save it
git branch rescue-branch abc123

[!TIP]
Reflog entries expire after 30 days for unreachable commits and 90 days for reachable ones. Act quickly!

Part 7: The Mental Model Summary

After all this, here's the simple truth:

Git Is a Content-Addressable Filesystem

Concept	Reality
Repository	A folder called `.git` with a key-value database
Blob	File content, addressed by SHA-1 hash
Tree	Directory listing, addressed by SHA-1 hash
Commit	Metadata pointing to a tree + parent
Branch	A text file containing a commit hash
HEAD	A text file saying which branch you're on
`git add`	Create blob, update index
`git commit`	Create tree + commit, update branch pointer

Visual Summary

┌─────────────────────────────────────────────────────────────────────────────┐
│                           GIT'S ARCHITECTURE                                │
└─────────────────────────────────────────────────────────────────────────────┘

                    You (HEAD)
                        │
                        ▼
                   ┌─────────┐
                   │  main   │  ← Branch (text file)
                   └────┬────┘
                        │ (contains hash)
                        ▼
                   ┌─────────┐
                   │ Commit  │  ← Commit object
                   │ abc123  │
                   └────┬────┘
                        │ (tree pointer)
                        ▼
                   ┌─────────┐
                   │  Tree   │  ← Root directory
                   │ 111aaa  │
                   └────┬────┘
                        │ (blob and tree pointers)
            ┌───────────┼───────────┐
            ▼           ▼           ▼
       ┌────────┐  ┌────────┐  ┌────────┐
       │  Blob  │  │  Blob  │  │  Tree  │
       │ file1  │  │ file2  │  │  src/  │
       └────────┘  └────────┘  └────────┘

Conclusion: Why This Knowledge Matters

Understanding Git's internals transforms you from a command-memorizer to a confident user:

Before	After
"I ran reset and lost my work!"	"I know it's in reflog for 30 days"
"Detached HEAD is scary"	"Just means HEAD points to hash, not branch"
"Branches are expensive to create"	"They're just 41-byte text files"
"Git is mysterious"	"Git is a key-value store with pointers"

Your Next Steps

Explore your own .git folder — Run the commands from Part 6
Create a throwaway repo and experiment — Break things on purpose
Read the hash — When you see error messages with hashes, you now know what they mean

The key insight: Every complex Git operation (rebase, cherry-pick, reset) is just manipulating objects and pointers. Once you see the database, the commands become obvious.

You now understand Git better than 90% of developers. Use this power wisely. 🚀

Have questions? Found this helpful? Let me know in the comments below!

Mastering Version Control: A Complete Guide to Git for Developers

Pratham — Sat, 31 Jan 2026 17:14:19 +0000

If you've just read about the pendrive nightmare, you know the old way was chaos. But how does Git actually solve this in a real company environment?

This isn't a boring command reference. I'll walk you through Git the way you'll actually use it at work—from cloning the company repo to getting your code merged into production.

What makes this guide different:

Structured around the actual workflow companies use
Commands introduced when you need them (Just-in-Time Learning)
Undo operations at every step (because mistakes happen)
The "why" behind every command, not just the "what"

Let's get started.

Part 1: The Mental Model

What is Git?

Git is a distributed version control system that tracks changes in your code.

In plain English: Git is a time machine + collaboration manager for your code.

"Version Control System" means:

It tracks every change you make to your code
It remembers what your code looked like yesterday, last week, or last year
It lets you go back to any previous version instantly
It shows you exactly what changed between versions

"Distributed" means:

Everyone on your team has a complete copy of the entire project history
You don't need internet to work or save your progress
If the server crashes, anyone can restore everything
No single point of failure

Why Every Company Uses Git

Reason 1: Time Travel for Your Code

Remember Piyush with 23 "FINAL" folders? That never happens with Git.

# See all previous versions
git log --oneline

# Compare today with last week
git diff HEAD~7

# Go back to any version
git checkout abc123

Reason 2: Safe Collaboration

When two developers edit the same file, Git doesn't silently delete anyone's work. Instead:

Developer A edits checkout.js and commits
Developer B edits checkout.js and tries to push
Git says: "Hold on! There are changes you haven't seen. Let me help you merge them."
Both changes are preserved

Reason 3: Experiment Without Fear

Want to try a risky redesign? Create a branch, experiment freely. If it fails, delete the branch. If it works, merge it in. Main code stays safe either way.

Reason 4: Know Who Did What

git blame payment.js

# Output:
# abc123 (Piyush  2025-12-10) function processPayment() {
# def456 (Hitesh  2025-12-11)   if (amount > 0) {

When a bug appears, you know exactly who to ask.

Reason 5: Work From Anywhere

Before the flight: git pull (get latest code)
On the flight: Work offline, commit progress
After landing: git push (sync with team)

No 100MB ZIP files. No airport WiFi struggles.

Part 2: Setup (Do This Once)

Configure Your Identity

Every commit you make will be stamped with this information:

# Set your name (appears in commits)
git config --global user.name "Your Name"

# Set your email (appears in commits)
git config --global user.email "your.email@company.com"

# Set default branch name to 'main'
git config --global init.defaultBranch main

# Verify your settings
git config --list

Why this matters: When something breaks, the team needs to know who wrote that code—not to blame, but to ask questions.

Part 3: The Company Workflow

This is how professional development teams work. Follow this flow for every feature you build.

Step 1: Clone the Main Repository

What it does: Downloads the complete project
(including all history) to your computer.

On GitHub, navigate to the main page of the repository.

Above the list of files, click  Code.

To clone the repository using HTTPS, under "HTTPS", 
click on copy icon.

To clone the repository using an SSH key, including 
a certificate issued by your organization's 
SSH certificate authority, click SSH, then click on copy icon.

To clone a repository using GitHub CLI, click GitHub CLI, 
then click on copy icon.

Change the current working directory to the location 
where you want the cloned repository.

Type git clone, and then paste the URL you copied earlier.

git clone https://github.com/USERNAME/REPOSITORY-NAME.git
Press Enter to create your local clone.

$ git clone https://github.com/USERNAME/REPOSITORY-NAME.git
> Cloning into `Spoon-Knife`...
> remote: Counting objects: 10, done.
> remote: Compressing objects: 100% (8/8), done.
> remove: Total 10 (delta 1), reused 10 (delta 1)
> Unpacking objects: 100% (10/10), done.

This creates:
project-name/
  ├── all project files
  └── .git/          ← Complete history lives here

What happens:

Creates a folder with the repository name
Downloads all files and complete history
Sets up a connection called "origin" pointing to the company repo.
Checks out the default branch (usually main)

UNDO: Cloned to wrong location?
Just delete the folder and clone again. Nothing on the server is affected.

[!TIP]
SSH vs HTTPS: For repositories you'll push to frequently, use SSH:
git clone git@github.com:company/repo-name.git
Why? SSH uses key-based authentication, so you won't need to enter your password for every push. Set up SSH keys once, and Git remembers you.

Step 1.5: Understanding What You Just Cloned

Now that you have a real repository on your machine, let's understand how Git organizes your work.

Diagram: The Three Stages of Git

Think of it like working in an office:

Working Directory = Your desk with all your documents and tools (This is where you actively work on things — all files that exist on your computer.)
Staging Area = The stack of papers you put in the “ready to finalize” tray (You choose specific documents you want to prepare for submission or final processing.)
Repository = The archive cabinet where final approved documents are stored (This is the permanent record

Exploring the .git Folder

Look inside your cloned project. There's a hidden .git folder that contains everything:

# View the .git folder structure
ls -la .git/

# Output:
.git/
  ├── HEAD              ← "You Are Here" marker
  ├── config            ← Repository settings
  ├── refs/
  │   ├── heads/        ← Local branch pointers
  │   │   └── main      ← Just a text file!
  │   └── remotes/      ← Remote branch pointers
  ├── objects/          ← All your files and commits (compressed)
  └── logs/             ← Reflog (your safety net)

Try this yourself:

# See what HEAD contains
cat .git/HEAD
# Output: ref: refs/heads/main

# See what the 'main' branch points to
cat .git/refs/heads/main
# Output: a1b2c3d4e5f6g7h8i9j0... (40-character commit hash)

[!NOTE]
A branch is just a 40-character text file. That's it. Branches are incredibly lightweight—creating one takes microseconds.

Diagram: Local Repository Structure

┌──────────────────────────────────────────────────┐
│            LOCAL REPOSITORY STRUCTURE            │
└──────────────────────────────────────────────────┘

  📁 my-project/
  │
  ├── 📄 index.html           ┐
  ├── 📄 style.css            ├── Your working files (visible)
  ├── 📄 app.js               ┘
  │
  └── 📁 .git/                     ← HIDDEN FOLDER (all the magic)
      │
      ├── HEAD                     ← "You are on: main"
      │   └─→ refs/heads/main
      │
      ├── refs/heads/
      │   ├── main → abc123        ← Branch pointer (text file)
      │   └── feature → def456     ← Another branch
      │
      ├── objects/
      │   ├── ab/c123...           ← Commit objects
      │   ├── de/f456...           ← Tree objects (folders)
      │   └── 12/3abc...           ← Blob objects (file contents)
      │
      └── logs/
          └── HEAD                 ← Reflog: everywhere HEAD has been

What is HEAD?

HEAD is a pointer that tells Git "where you currently are."

Normal State (Safe):

HEAD ──→ refs/heads/main ──→ Commit abc123
         (branch name)       (actual commit)

When you make a new commit, the branch moves forward automatically:

Before:
HEAD ──▶ main ──▶ C ──▶ B ──▶ A

After:
HEAD ──▶ main ──▶ D ──▶ C ──▶ B ──▶ A

Detached HEAD State (Dangerous):

When you checkout a specific commit instead of a branch:

git checkout abc123    # A specific commit, not a branch name

Now HEAD points directly to the commit, bypassing the branch:

HEAD ──→ Commit abc123
         (no branch involved!)

Why Detached HEAD is Dangerous

The Problem: In detached HEAD, if you make new commits, they have no branch protecting them.

Before (on main):
HEAD → main → C    (where A ← B ← C is the history)

You checkout commit B (detached):

       main → C
              ↑
        A ← B ← C
            ↑
          HEAD (detached - pointing directly to B)

You make a new commit D while detached:

       main → C
              ↑
        A ← B ← C
            ↑
            D ← HEAD

You switch back to main:

       main → C ← HEAD
              ↑
        A ← B ← C
            ↑
            D (ORPHANED! No branch points to it)

Where is D? It has NO REFERENCE pointing to it!

The Rule: Git deletes objects with zero references pointing to them.

Reference Type	Example	Protects Commits?
Branch name	`main`, `feature-x`	✅ Yes
Tag	`v1.0.0`	✅ Yes
HEAD (on a branch)	`HEAD` → `main` → commit	✅ Yes
Detached HEAD	`HEAD` → commit directly	❌ Only while you're there!

The moment you leave a detached commit, it becomes eligible for garbage collection.

The Chain of Custody: Why Old Commits Survive

You might wonder: "If main only points to the latest commit, why aren't old commits deleted?"

Answer: Commits point backward to their parents.

main ──→ C ──→ B ──→ A ──→ (initial)
         │     │     │
       parent parent parent

Git's garbage collector runs a reachability check:

Start at all branch pointers and tags
Follow parent links backward
Mark everything reachable as "alive"
Delete anything not reachable

Reachability Check:
┌─────────────────────────────────────────────────────────────────┐
│  main → C → B → A                                               │
│         ✓   ✓   ✓   All reachable from main = PROTECTED        │
│                                                                 │
│  Orphan commit D (from detached HEAD)                           │
│         ✗   No branch or tag points to it = WILL BE DELETED    │
└─────────────────────────────────────────────────────────────────┘

The 30-Day Grace Period

Good news: orphaned commits aren't deleted immediately.

Git's reflog keeps a record of everywhere HEAD has been for 30-90 days (depending on configuration).

git reflog

# Output:
e4f5g6h HEAD@{0}: checkout: moving from detached to main
d123456 HEAD@{1}: commit: my orphan commit        ← Still recoverable!
abc123  HEAD@{2}: checkout: moving from main to abc123

Recovery:

# Find the orphan commit hash in reflog
git reflog

# Create a branch to save it
git branch rescue-my-work d123456

# Now it's protected!

[!TIP]
Reflog entries expire after 30 days for unreachable commits and 90 days for reachable ones. Recover lost work promptly!

Quick Fix: Escaping Detached HEAD

If you see this warning:

You are in 'detached HEAD' state...

Option 1: Create a branch to keep your work:

git checkout -b my-new-branch
# Now you're safe—a branch protects your commits

Option 2: Go back to an existing branch:

git checkout main
# Warning: Any commits you made while detached may be lost!

Step 2: Create Your Feature Branch

The Golden Rule: Never work directly on main. Always create a feature branch.

# First, make sure you have the latest main
git checkout main
git pull origin main

# Create AND switch to a new branch
git checkout -b feature/user-authentication

# Or the modern way (Git 2.23+)
git switch -c feature/user-authentication

Why branches?

main:        ──●──●──●──●─────────────────●── (stable, production-ready)
                    \                     /
your-feature:        ●──●──●──●──●──●────     (your work, isolated)

Your experiments won't break the main code
Multiple features can be developed simultaneously
Easy to abandon failed experiments
Clean history of what changed for each feature

Branch Naming Conventions:

Prefix	Use For	Example
`feature/`	New features	`feature/dark-mode`
`bugfix/`	Bug fixes	`bugfix/login-timeout`
`hotfix/`	Urgent production fixes	`hotfix/security-patch`

UNDO: Created branch with wrong name?
git branch -m old-name new-name

Step 3: Work on Your Feature

This is where you spend most of your time. The cycle is: Edit → Stage → Commit → Repeat.

📁 Real-World Example: Building a Login Page

Let's walk through a complete example with actual files and terminal output.

Starting Point: You've created a feature branch and are ready to work.

# You're on your feature branch
git branch
#   main
# * feature/login-page

Step A: Create a new file

Create login.html:

<!-- login.html -->
<!DOCTYPE html>
<html>
<head>
    <title>Login</title>
</head>
<body>
    <h1>Login to Your Account</h1>
    <form>
        <input type="email" placeholder="Email" />
        <input type="password" placeholder="Password" />
        <button type="submit">Login</button>
    </form>
</body>
</html>

Check what Git sees:

git status

# Output:
On branch feature/login-page
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        login.html

nothing added to commit but untracked files present

Git sees the new file but isn't tracking it yet (red text if using colors).

Step B: Stage the file

git add login.html

git status

# Output:
On branch feature/login-page
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   login.html

The file is now in the staging area (green text), ready to be committed.

Step C: Commit the file

git commit -m "feat: add basic login page structure"

# Output:
[feature/login-page 3f2a1b9] feat: add basic login page structure
 1 file changed, 14 insertions(+)
 create mode 100644 login.html

Step D: Modify an existing file

Now add some CSS. Edit login.html:

<!-- login.html (modified) -->
<!DOCTYPE html>
<html>
<head>
    <title>Login</title>
    <link rel="stylesheet" href="login.css">   <!-- NEW LINE -->
</head>
<body>
    <h1>Login to Your Account</h1>
    <form>
        <input type="email" placeholder="Email" />
        <input type="password" placeholder="Password" />
        <button type="submit">Login</button>
    </form>
</body>
</html>

And create login.css:

/* login.css */
body {
    font-family: Arial, sans-serif;
    display: flex;
    justify-content: center;
    padding-top: 100px;
}

button {
    background: #007bff;
    color: white;
    padding: 10px 20px;
    border: none;
    cursor: pointer;
}

Check status:

git status

# Output:
On branch feature/login-page
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   login.html

Untracked files:
        login.css

Step E: See exactly what changed

git diff login.html

# Output:
diff --git a/login.html b/login.html
index 3f2a1b9..8c4d2e1 100644
--- a/login.html
+++ b/login.html
@@ -3,6 +3,7 @@
 <head>
     <title>Login</title>
+    <link rel="stylesheet" href="login.css">
 </head>

Lines starting with + are additions, - are deletions.

Step F: Stage and commit both files

# Stage both files
git add login.html login.css

git status

# Output:
On branch feature/login-page
Changes to be committed:
        modified:   login.html
        new file:   login.css

# Commit
git commit -m "style: add CSS styling to login page"

# Output:
[feature/login-page 7d4e2f3] style: add CSS styling to login page
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 login.css

Step G: View your commit history

git log --oneline -3

# Output:
7d4e2f3 (HEAD -> feature/login-page) style: add CSS styling to login page
3f2a1b9 feat: add basic login page structure
9abc123 (origin/main, main) Previous commit on main

Diagram: Commit History Flow

Now let's look at each individual command in detail:

3.1 Check Status (Do This Constantly!)

git status

# Output shows:
# - Modified files (changed but not staged)
# - Staged files (ready to commit)
# - Untracked files (new files Git doesn't know about)

Pro tip: Compact status format

git status -s

# Output:
#  M src/App.js          # Modified, not staged
# M  src/index.js        # Modified and staged
# ?? src/NewFile.js      # Untracked
# A  src/AddedFile.js    # New file, staged

Why use -s? When you're experienced, the full status output is verbose. -s gives you the same info in one line per file.

Make this a habit. Run git status before and after every operation. It's your dashboard.

3.2 Stage Your Changes

git add moves changes to the staging area—preparing them for commit.

Why staging exists: You might change 10 files but only want to commit 3 of them as one logical change. Staging lets you curate your commits, keeping each one focused on a single purpose.

# Stage specific file (when you want precise control)
git add src/login.js

# Stage multiple files
git add src/login.js src/auth.js

# Stage all changes in current directory
git add .

# Stage part of a file (interactive—powerful!)
git add -p src/login.js

Choosing the Right Staging Command:

Command	What It Does	When to Use
`git add <file>`	Stages one specific file	When you want precise control over what's committed
`git add .`	Stages all changes in current directory and subdirectories	Quick staging when all changes belong together
`git add -A`	Stages all changes in entire repository	When you made changes in multiple directories
`git add -u`	Stages only already-tracked files	When you don't want to add new files
`git add -p`	Interactive staging (select parts of files)	When you made multiple unrelated changes in one file

Why git add -p is powerful:

Imagine you fixed a bug AND added a new feature in the same file. With -p, you can commit them separately:

git add -p src/user.js
# Git shows each change and asks:
# y = stage this chunk
# n = don't stage this chunk
# s = split into smaller chunks
# q = quit

Real-world scenario: You're working on login and accidentally fix a typo in a comment. Stage the login code first, commit it, then stage and commit the typo fix separately. Clean history!

UNDO: Staged wrong file?
git reset src/wrong-file.js
# or (Git 2.23+)
git restore --staged src/wrong-file.js
Why two commands? git restore is newer (Git 2.23) and clearer in intent. Both work the same, but restore explicitly says "I'm restoring the staged state."

3.3 Review What You're About to Commit

# See unstaged changes
git diff

# See staged changes (what will be committed)
git diff --staged

# Output shows:
# - lines (deleted)
# + lines (added)

Always review before committing. This prevents "wait, did I change that?" moments.

3.4 Commit Your Changes

A commit is a permanent snapshot of your staged changes.

git commit -m "feat: add user login form validation"

Writing Good Commit Messages:

# ❌ BAD - tells nothing
git commit -m "fixed stuff"
git commit -m "update"
git commit -m "wip"

# ✅ GOOD - clear and searchable
git commit -m "fix: resolve login timeout on slow connections"
git commit -m "feat: add dark mode toggle to settings"
git commit -m "docs: update API authentication examples"

Conventional Commit Format:

Type	When to Use
`feat:`	New feature
`fix:`	Bug fix
`docs:`	Documentation only
`style:`	Formatting (no code change)
`refactor:`	Code restructuring
`test:`	Adding tests
`chore:`	Maintenance tasks

Why good messages matter: Six months later, you'll search through history to find when a bug was introduced. Would you rather search through "fixed stuff" or "fix: validate email format before API call"?

UNDO: Made a mistake in last commit?
# Fix the message
git commit --amend -m "correct message here"

# Add a forgotten file to last commit
git add forgotten-file.js
git commit --amend --no-edit
[!WARNING]
Don't amend commits you've already pushed to a shared branch!

3.5 Stash: Temporary Work Storage

Scenario: You're mid-feature, but need to switch branches for an urgent bug fix. You can't commit half-done work.

# Save your work temporarily
git stash push -m "WIP: login form halfway done"

# Your working directory is now clean
git switch main
# ... fix the bug, commit, push ...

# Return to your feature
git switch feature/user-authentication

# Restore your work
git stash pop

# Your half-done work is back!

Stash Commands:

Command	What It Does	When to Use
`git stash`	Stash all changes	Quick save when you need to switch immediately
`git stash push -m "desc"`	Stash with description	Recommended — you'll know what's in each stash
`git stash list`	Show all stashes	See what you've stashed before
`git stash pop`	Restore AND delete the stash	When you're sure you want to apply it
`git stash apply`	Restore but KEEP the stash	When you might need the same stash on multiple branches
`git stash drop`	Delete without restoring	When you no longer need a stash

Why pop vs apply?

Use pop (90% of the time): You stashed, switched, fixed the bug, and now you're back. Pop and continue.
Use apply (10% of the time): You have a utility change you want to apply to multiple branches. Apply keeps the stash for reuse.

UNDO: Popped wrong stash?
The stashed changes are now in your working directory. If you need to undo, just stash again or use git checkout -- . to discard.

3.6 View History

# See commit history
git log

# Compact one-line format
git log --oneline

# Last 5 commits with graph
git log --oneline --graph -5

# History of specific file
git log -- src/login.js

UNDO: Need to discard ALL changes and start fresh?

git checkout -- .                    # Discard unstaged changes
# or (Git 2.23+)
git restore .

Step 4: Sync with Main (The Critical Step)

While you were working, your teammates pushed changes to main. Your branch is now outdated. Before pushing, you must sync.

Why this matters: If you try to merge outdated code, conflicts explode during the PR. The person who wrote the code (you) is best equipped to resolve conflicts, not the reviewer.

[!IMPORTANT]
The Golden Rule of Conflicts: You should never leave conflicts for the Senior Dev or Maintainer to solve. They don't know why you changed a specific line of code. If they try to fix your conflict, they might accidentally delete your new logic.

Two Approaches: Rebase vs Merge

The Train Track Analogy (from company-workflow.md):

Approach	Visualization	History Result
Rebase	Pick up your train car and place it at the front of the train	Single straight line
Merge	Build a side track that loops out and joins back	Loop/diamond shapes ("bubbles")

Why it matters: If 20 developers all use merge constantly, the history graph looks like a tangled bowl of spaghetti. Rebase keeps it clean.

	Rebase	Merge
Command	`git rebase main`	`git merge main`
History	Linear (straight line)	"Bubbles" (diamonds)
Result	Looks like you just wrote code on latest main	Preserves when parallel work happened
Team Preference	Modern teams prefer	Some teams require

Approach A: Rebase (Preferred for Clean History)

# 1. Switch to main and get latest
git checkout main
git pull origin main

# 2. Switch back to your branch
git checkout feature/user-authentication

# 3. Rebase onto main
git rebase main

What rebase does:

BEFORE REBASE:
                 (main moved forward while you worked)
                              ↓
main:       A ── B ── C ── D
                 ↑
                 └── E ── F  ← your-branch (branched from B)

AFTER REBASE:
main:       A ── B ── C ── D
                           ↑
                           └── E' ── F'  ← your-branch

Your commits E and F are "replayed" on top of D (latest main).
E' and F' are NEW commits with different hashes but same changes.

If conflicts occur during rebase:

# Git stops and shows conflicted files
git status

# 1. Open each conflicted file
# 2. Look for conflict markers:
<<<<<<< HEAD
code from main
=======
your code
>>>>>>> your-commit

# 3. Edit to keep what you want, remove markers
# 4. Stage the resolved file
git add resolved-file.js

# 5. Continue rebase
git rebase --continue

UNDO: Rebase going badly?

git rebase --abort    # Cancels rebase, returns to before you started

Approach B: Merge (When Rebase is Banned)

Some teams forbid rebase because it rewrites history. In that case:

# While on your feature branch
git merge main

What merge does:

BEFORE MERGE:
                 (main moved forward while you worked)
                              ↓
main:       A ── B ── C ── D
                 ↑
                 └── E ── F  ← your-branch (branched from B)

AFTER MERGE (you run 'git merge main' on your branch):

main:       A ── B ── C ── D ─────────────────┐
                 ↑                            ↓
                 └── E ── F ────────────── M ← your-branch
                                      (merge commit)

M is a "merge commit" with TWO parents: F (your work) and D (main).
This creates a "diamond" or "bubble" in history.

Resolving merge conflicts: Same process as rebase—edit files, remove markers, git add, then git commit.

UNDO: Merge going badly?

git merge --abort    # Cancels merge, returns to before you started

Step 5: Push to Remote

Your branch is synced with main and conflicts are resolved. Time to upload.

# First-time push (sets upstream tracking)
git push -u origin feature/user-authentication

# Subsequent pushes
git push

If you rebased after already pushing:

Rebase rewrites commit history. If you pushed before rebasing, you need to force push:

git push --force-with-lease origin feature/user-authentication

[!CAUTION]
--force-with-lease is safer than --force. It fails if someone else pushed to your branch, preventing you from overwriting their work.

[!CAUTION]
NEVER force push to main or any shared branch! This rewrites history for everyone.

UNDO: Pushed wrong code?

For pushed commits, use git revert (safe—creates an "undo" commit):
git revert abc123    # Creates new commit that undoes abc123
git push
Don't use git reset on pushed commits—it rewrites history others depend on.

Step 6: Create Pull Request (PR)

On GitHub/GitLab, create a Pull Request to merge your branch into main.

A Good PR Includes:

Clear title describing the change
Description of what and why
Screenshots for UI changes
Links to related issues

What Happens Next:

Teammates review your code
They may request changes
You make changes, commit, push (branch auto-updates PR)
Once approved, PR is merged

Step 7: Squash and Merge

This is typically done by the approver (senior dev or team lead), not you.

What "Squash and Merge" does:

YOUR PR COMMITS:
E: "feat: add login form"
F: "fix: typo in label"
G: "style: adjust button padding"
H: "fix: forgot validation"

AFTER SQUASH:
S: "feat: add user authentication (#123)"

All your messy WIP commits become one clean commit on main.

Why squash: Main branch history stays clean and readable. Each commit represents one complete feature, not a stream of consciousness.

Step 8: Cleanup

After your PR is merged:

# Switch to main
git checkout main

# Get the merged changes
git pull origin main

# Delete local feature branch (it's merged, you don't need it)
git branch -d feature/user-authentication

# Delete remote feature branch (optional, GitHub can auto-delete)
git push origin --delete feature/user-authentication

Why -d vs -D?

Flag	What It Does	When to Use
`-d` (lowercase)	Safe delete — only works if branch is fully merged	Normal cleanup after PR merge
`-D` (uppercase)	Force delete — deletes even if not merged	Abandoning a failed experiment

Reasoning: Use -d by default. Git will refuse if you'd lose unmerged work. Only use -D when you intentionally want to discard unmerged commits.

Congratulations! You've completed the full company workflow. Repeat for every feature.

Part 4: Recovery and Safety Net

Mistakes happen. Git has your back.

The Reflog: Your Time Machine

The reflog tracks everywhere HEAD has been—even "deleted" commits.

git reflog

# Output:
e4f5g6h HEAD@{0}: reset: moving to HEAD~3
a1b2c3d HEAD@{1}: commit: my important work    ← "deleted" commit is here!
9876543 HEAD@{2}: commit: previous work

Recover "lost" commits:

# Find the commit hash in reflog
git reflog

# Reset to that point
git reset --hard a1b2c3d

# Your work is back!

[!NOTE]
Reflog entries expire after 30 days for unreachable commits (like orphans) and 90 days for reachable commits. Recover lost work promptly!

The Complete Undo Cheatsheet

# ─────────────────────────────────────────────────────────────
# UNSTAGE A FILE (after git add, before commit)
# ─────────────────────────────────────────────────────────────
git reset <file>
# or (Git 2.23+)
git restore --staged <file>

# ─────────────────────────────────────────────────────────────
# DISCARD CHANGES IN A FILE (before staging)
# ─────────────────────────────────────────────────────────────
git checkout -- <file>
# or (Git 2.23+)
git restore <file>

# ─────────────────────────────────────────────────────────────
# UNDO LAST COMMIT (keep changes staged)
# ─────────────────────────────────────────────────────────────
git reset --soft HEAD~1

# ─────────────────────────────────────────────────────────────
# UNDO LAST COMMIT (keep changes unstaged)
# ─────────────────────────────────────────────────────────────
git reset HEAD~1

# ─────────────────────────────────────────────────────────────
# UNDO LAST COMMIT (DELETE changes completely) ⚠️
# ─────────────────────────────────────────────────────────────
git reset --hard HEAD~1

# ─────────────────────────────────────────────────────────────
# UNDO A PUSHED COMMIT (safe - creates "undo" commit)
# ─────────────────────────────────────────────────────────────
git revert <commit-hash>

# ─────────────────────────────────────────────────────────────
# RECOVER "LOST" COMMITS
# ─────────────────────────────────────────────────────────────
git reflog
git reset --hard <commit-from-reflog>

Understanding Reset Modes

                    Moves HEAD?   Clears Staging?   Clears Working Dir?
--soft                 ✓              ✗                   ✗
--mixed (default)      ✓              ✓                   ✗
--hard                 ✓              ✓                   ✓  ⚠️ DANGEROUS

Reset vs Revert: When to Use Which

Scenario	Use	Why
Undo local commit (not pushed)	`git reset`	Safe to rewrite local history
Undo pushed commit	`git revert`	Creates undo commit, preserves history
Nuclear option (reset to remote)	`git reset --hard origin/main`	Last resort

Part 5: Common Scenarios

"I committed to the wrong branch!"

# You're on main but should be on feature branch
# You just committed here by mistake

# 1. Create the correct branch (with your commit)
git branch correct-branch

# 2. Reset main back to before your commit
git reset --hard HEAD~1

# 3. Switch to correct branch
git checkout correct-branch

# Your commit is now on the correct branch!

"I have uncommitted changes and need to switch branches!"

# Option 1: Stash (if you want to keep changes)
git stash push -m "WIP: description"
git checkout other-branch
# ... do work ...
git checkout original-branch
git stash pop

# Option 2: Commit (if changes are ready)
git add .
git commit -m "WIP: save progress"
git checkout other-branch

"I'm in detached HEAD state!"

This happens when you checkout a specific commit instead of a branch.

# You see: "You are in 'detached HEAD' state"

# If you want to keep working here, create a branch:
git checkout -b my-new-branch

# If you want to go back to a branch:
git checkout main

"My branch is way behind main and has tons of conflicts!"

# Option 1: Incremental rebase (less overwhelming)
git rebase main
# Resolve conflicts one commit at a time

# Option 2: Squash your commits first, then rebase
git rebase -i HEAD~10    # Squash your 10 commits into 1
git rebase main          # Now only 1 commit to conflict-resolve

Part 6: Quick Reference Card

Daily Commands

git status                    # What's changed?
git add .                     # Stage all
git commit -m "message"       # Save snapshot
git push                      # Upload to remote
git pull                      # Download and merge
git log --oneline -10         # Recent history

Branch Operations

git branch                    # List branches
git checkout -b new-branch    # Create and switch
git checkout main             # Switch to main
git merge feature-branch      # Merge into current
git branch -d old-branch      # Delete branch

Sync Operations

git fetch origin              # Download without merging
git pull origin main          # Download and merge
git rebase main               # Replay commits on main
git push -u origin branch     # First push with tracking
git push --force-with-lease   # Force push (after rebase)

Undo Operations

git restore <file>            # Discard unstaged changes
git restore --staged <file>   # Unstage
git reset --soft HEAD~1       # Undo commit, keep staged
git reset HEAD~1              # Undo commit, unstage
git reset --hard HEAD~1       # Undo and delete ⚠️
git revert <commit>           # Create undo commit
git reflog                    # Find lost commits

Stashing

git stash                     # Save temporarily
git stash pop                 # Restore and delete
git stash list                # Show all stashes

What You've Learned

✅ The Mental Model: Git as time machine + collaboration manager

✅ The Three Stages: Working Directory → Staging → Repository

✅ The .git Folder: What HEAD, refs, and objects actually are

✅ The Company Workflow: Clone → Branch → Work → Sync → Push → PR → Merge → Cleanup

✅ Undo Operations: Reset, revert, restore, and reflog for every situation

✅ Best Practices: Conventional commits, branch naming, never force-push to main

Next Steps

Practice the workflow on a real project
Make mistakes intentionally and practice recovering
Use git status constantly until it's second nature
Read error messages—Git's errors are actually helpful

Pro tip: Every expert developer was once confused by Git. The difference is they kept practicing.

You've got this! 🚀

Have questions? Found this helpful? Let me know in the comments below!

Forem: Pratham

Emmet for HTML: A Beginner’s Guide to Writing Faster Markup

The Root: The "Carpal Tunnel" Problem

The Trunk: The Core Abbreviations

1. The Tag (The Species)

2. The Class (The Dot .)

3. The ID (The Hash #)

4. The Combination (Mixing Them)

Diagram: The Expansion Flow

The Branches: Advanced Power Moves

5. Multiplication (*)

6. The Child (>) aka Nesting

7. The Sibling (+) aka The Neighbor

8. Grouping (()) aka The Math Logic

The Ultimate Shortcut: The Boilerplate (!)

Summary Cheat Sheet

Conclusion: Speed is a Byproduct

CSS Selectors 101: Targeting Elements with Precision

The Root: The "Crowded Room" Problem

The Trunk: The Three Pillars of Targeting

1. The Element Selector (The "Megaphone Shout")

2. The Class Selector (The "Uniform")

3. The ID Selector (The "Passport Number")

Diagram: The Targeting Hierarchy

The Branches: Advanced Logic

4. The Grouping Selector (The "Meeting")

5. The Descendant Selector (The "Inside" Rule)

A Quick Note on Priority (Specificity)

Conclusion: Taming the Chaos

Understanding HTML: The Invisible Skeleton of the Web

1. The Hook: The Skeleton Beneath the Skin

2. The Roots: It's Not "Code", It's Layout

3. The Trunk: Anatomy of an Element (The Box)

The Distinction

Visual: Anatomy of an Element

The Void Elements (Self-Closing)

4. The Branches: The Laws of Physics (Block vs. Inline)

1. Block-Level Elements (div, h1, p, section)

2. Inline Elements (span, a, b, strong)

Visual: The Flow

5. The Leaves: Professional Depth (Semantics)

The Problem with <div> (The Generic Box)

Semantic HTML (The Meaningful Box)

6. Conclusion: Build Better Skeletons

How a Browser Works: The Invisible Factory Inside Your Screen

1. The Hook: The "Black Box" Moment

2. The Roots: The Problem of Translation

Computers vs. Humans

3. The Trunk: The Factory Managers (High-Level Architecture)

The 7 Key Components

Visual: The Factory Map

4. The Branches: The Critical Rendering Path

Step 1: Parsing HTML (Building the Frame)

Step 2: Parsing CSS (The Interior Design)

Step 3: The Render Tree (The Construction Plan)

Step 4: Layout (The Geometry Phase)

Step 5: Paint (The Texture Phase)

Step 6: Composition (The Assembly Phase)

5. The Leaves: Optimization & Dynamics

Reflow (Layout) vs. Repaint vs. Composite

Visual: The Full Pipeline

6. Conclusion: The Miracle in 500ms

TCP vs UDP: The Rules of the Digital Road (And Where HTTP Fits)

1. The Roots: The Problem with the "Wild West" Internet

The Chaos

2. The Trunk: Two Managers, Two Philosophies

A. TCP (Transmission Control Protocol) - "The Obsessive Accountant"

B. UDP (User Datagram Protocol) - "The Speed Demon"

3. The Branches: The Deep Dive Comparison

Scenario 1: Developing a Chat App (WhatsApp/Discord Text)

Scenario 2: Developing a Video Game (Call of Duty / Valorant)

Visual Comparison

Table of Truth

4. The Leaves: Where HTTP Fits (The Application)

The Stack Explained

Visual: The "Packet Matryoshka Doll"

Summary Check

5. Conclusion: The Tree of Knowledge

Next Steps for You

TCP Explained: The Invisible Handshake Governing the Internet

2. The Class (The Dot `.`)

3. The ID (The Hash `#`)

5. Multiplication (`*`)

6. The Child (`>`) aka Nesting

7. The Sibling (`+`) aka The Neighbor

8. Grouping (`()`) aka The Math Logic

1. Block-Level Elements (`div`, `h1`, `p`, `section`)

2. Inline Elements (`span`, `a`, `b`, `strong`)

The Problem with `<div>` (The Generic Box)