This is exactly what happens on the internet if the data is sent without rules or protocols.

Networks are not always reliable.
Sometimes networks are noisy.
Data packets can be lost, duplicated, or arrive out of order.

So now the big question is:

“How do computers communicate reliably over the network?”

This is where TCP and UDP come into the picture. They are designed to handle data transmission in different ways, depending on the situation and the level of reliability required.

Two Protocols, Two Different Goals

Let’s look at two simple scenarios:

1. A user wants to deliver a package to a friend, so he chooses a courier service. He hands over the parcel and receives a tracking number. The courier confirms when the package is picked up and when it is delivered. Everything is delivered in the correct order. If something is lost along the way, it is resent. The delivery might take a little longer, but it is guaranteed.

   This is exactly how TCP works.

2. Imagine a live radio broadcast. The broadcaster sends the message only once. There is no confirmation that every listener received it. If something is missed or lost due to noise or interference, it is gone forever. Nothing is resent, and the broadcast keeps moving forward.

   This is how UDP works.

Both approaches solve communication problems but with different goals.
TCP focuses on reliability, ordering, loss detection, retransmission, and correctness, while UDP focuses on speed and real-time delivery.

So, a natural question arises:

“How do TCP and UDP actually send data differently under the hood?”

How do TCP and UDP actually send data differently under the hood?

TCP: “Connection First, Data Later”

Before sending any data, TCP first establishes a connection using the 3-way handshake:

1. SYN – “Am I audible?”

2. SYN-ACK – “Yes, I can hear you.”

3. ACK – “Let’s start.”

Only after this handshake does, TCP begins, sending data and reliability by:

• Numbering each packets.

• Sending data in ordered format.

• Waits for acknowledgements.

• Retransmits lost packets.

• Controlling speed to avoid congestion.

This makes TCP slow but more reliable.

UDP: “Send and Move on”

UDP is connectionless, there is no handshake, no setup, and no confirmation.

When application sends data using UDP:

• The data is sent immediately.

• There is no check for the receiver status, is ready than send the data.

• There are no acknowledgements.

• Lost packets are not retransmitted.

• Packets may arrive out of order.

This makes UDP fast but less reliable.

But as developers, we should ask:

“When should we use TCP, and when should we use UDP in real applications?”

Let’s find out.

When should we use TCP, and when should we use UDP in real applications?

Now that we understand how TCP and UDP work, the next question is when should we use each of them in real applications?

When to Use TCP?

Use TCP when:

• Data must be delivered in the correct order.

• Data must not be lost.

• Acknowledgements are required after successful transmission.

• Accuracy and reliability are critical.

In these cases, TCP ensures reliable communication.

Real-world examples:

• Web browsing

• Email

• File downloads

• APIs

When to Use UDP?

Use UDP when:

• Speed matters more than accuracy.

• Small data loss is acceptable.

• Real-time delivery is more important than perfect reliability.

In these cases, UDP sacrifices reliability for speed.

Real-world examples:

• Video streaming

• Online gaming

• Live broadcasts

• Voice and video calls

Now, we are understood both the TCP and UDP, but another question comes to mind:

“What is HTTP, why do we use it, and how is it related to TCP?”

This is where the concept of HTTP comes into the picture.

TCP and HTTP?

We can think like:

TCP ensures data arrives correctly.
HTTP defines what that data represents.

Specifically, HTTP defines:

• How requests and responses are structured?

• Methods like GET, POST, PUT, DELETE?

• Status codes such as 200, 404, 500 and many more.

HTTP does not send data by itself. It relies on lower-level transport protocols to move data across the network, this is where TCP comes in picture.

The Relationship Between TCP and HTTP

HTTP runs on top of TCP.

A simple way to think about this:

• TCP = the delivery truck.

• HTTP = the instructions inside the package.

TCP makes sure the data arrives safely and in the correct order.

HTTP explains what that data represents and how it should be interpreted.

Why HTTP Does Not Replace TCP?

HTTP cannot replace TCP because it does not handle:

• Orderning of packets

• Connection management

• Reliable delivery

• Retransmission

• Acknowledgement

Those responsibilities belong entirely to TCP.

HTTP and TCP are not competitors.
You can think like HTTP is a wrapper around TCP.
They are partners, each solving a different part of the communication.

Big Picture

Each protocol has a clear responsibility, and none of them exist by accident.

It start feeling like tools for communication at different layers of the network.

You open a browser and visit a website like kartikeynarayan.in on your mobile phone, laptop, or any other device. The website loads instantly, without you needing to think about what happens behind the scenes.

But have you ever wondered how your browser actually reaches the website you requested?

Computers or browsers do not understand the domain name. They communicate using IP addresses, which tell them exactly where to go.

So before the website loads, something very important happens in the background:

kartkeynarayan.in → convert it into → 192.1.2.1

So that process, which is running in background which convert the domain name to an IP address is called DNS resolution.

Now, let’s dive deeper into DNS resolution and understand how this process works under the hood.

Internet Phone Book

To understand DNS resolution, we first need to clearly understand what DNS means?

As discussed earlier, DNS converts a domain name into an IP address so that the browser knows where to go and can load the website. Browsers and computers communicate using IP addresses, not domain names.

You can think of DNS as the internet’s phonebook.

Just like a phonebook contains names and their corresponding phone numbers, DNS contains domain names and their corresponding IP addresses in form of different DNS record types. These entries guide the browser by providing instructions on how to reach the final destination.

DNS exists because remembering IP addresses is not practical for humans. Instead of memorizing numbers like 192.1.2.1, we use easy-to-remember names like kartikeynarayan.in, and DNS handles the translation in the background.

But here the catch, even we are thinking that it is a simple task, converting a domain name to IP address, multiple systems and servers work together behind the scene.

So, a natural question arises:

“Who is Involved in DNS Resolution?”

Who is Involved in DNS Resolution?

Before understanding DNS resolution, how the process works and how the conversion happens between the client and the server. We first need to identify the key players involved.

Think of it like a match. Every match has players, and each player has a specific role. If we know the players and their roles in advance, it becomes much easier to understand what happens during the game.

When you type a domain name into a browser, several components (players) work together to convert that domain name into an IP address. The browser then uses this IP address to reach its final destination.

The key players involved are:

• Browser – Starts the request.

• Operating System (OS) Cache – Checks if the answer is already known.

• Recursive DNS Resolver – Finds the answer on behalf of the browser.

• Root DNS Server – Knows where top-level domains live.

• TLD DNS Server – Handles domains like .com, .in, .org, and many more.

• Authoritative DNS Server – Stores the final DNS records.

This whole thing ensures that DNS queries are resolved efficiently and reliably.

Now, another natural question arises:

“How does this process actually work under the hood?”

How does this process actually work under the hood?

Now we have reached where everything becomes interesting.

This is the moment when we finally see what actually happens behind the scenes when you visit a website like kartikeynarayan.in on our browsers.

Although the page loads in a second, several systems and components work together very quickly and very quietly.

Let’s walk through this journey step by step.

• Browser Check:

  When we type kartikeynarayan.in into the browser and press Enter, the browser doesn’t immediately ask the internet.

  First, it asks itself:

  “Do I already know the IP address for this domain?”

  Browsers store recently resolved domain names in a DNS cache. If the browser finds the IP address here, the process stops immediately and the website loads faster. If not, the browser moves to the next level.

• OS Cache Check

  When we are here, the browser asks the operating system:

  “Have you resolved this domain recently?”

  The operating system also maintains its own DNS cache, shared by all applications on the system.

  • If the OS finds the IP address, it returns it to the browser.

  • If not, the request moves forward to the next component or server or system.

If there is still no answer?
Then the real DNS journey begins from this point.

• Recursive Resolver

  Now the request is sent to a recursive DNS resolver.

  The browser’s message to the resolver is simple:

  “Please find the IP address for kartikeynarayan.in.”

  From this point onward, the resolver takes full responsibility. The browser waits, and the resolver does all the hard work.

• Root DNS Server

  The recursive resolver doesn’t know the answer yet, so it starts at the top of the DNS hierarchy which is the starting point of the internet.

  It asks a root DNS server:

  “Do you the IP address of kartikeynarayan.in?”

  The root server doesn’t know the IP address of the website. Instead, it responds with a direction:

  “I don’t know the IP address, but I know who manages .in domains.”

  It then points the resolver to the TLD DNS server.

• TLD DNS Server

  Now, The resolver contacts the Top-Level Domain (TLD) DNS server for .in domain.

  The resolver asks:

  “Do you the IP address of kartikeynarayan.in?”

  The TLD server replies:

  “I don’t know the IP address, but this is the authoritative DNS server for that domain.”

  Now the resolver knows exactly where to go next.

• Authoritative DNS Server

  The resolver now contacts the authoritative DNS server for kartikeynarayan.in. This server holds the actual DNS records.

  The resolver asks:

  “Do you the IP address of kartikeynarayan.in?”

  The authoritative server responds with the final answer:

  Yes, I know the IP address of kartikeynarayan.in, here the details

  • A record → IPv4 address

  • AAAA record → IPv6 address ( in case of IPv6 IP address )

This is the source of truth.
No more guessing.

• Response to Browser

  Now something important happens. The answer travels back the same path it came from:

  • Authoritative server → Recursive resolver

  • Recursive resolver → OS

  • OS → Browser

At each level, the IP address is cached for future use (based on TTL). This means the next request will be faster.

• Browser Loads the Website

  Finally, the browser has what it needs.

  It uses the IP address to:

  • Connect to the web server.

  • Send an HTTP/HTTPS request.

  • Download HTML, CSS, JavaScript, images.

And the website appears on your screen. All of this happens in milliseconds.

Big Picture

After understanding the data flow from the starting point to the final destination and back again, the bigger picture becomes clear.

DNS works smoothly because:

• Caching reduces repeated work.

• Responsibility is clearly divided between servers.

• The system is hierarchical and scalable, allowing it to grow as needed.

• Recursive resolvers do the heavy lifting on behalf of the browser.

It looks like magic is actually a well-designed, recursive lookup system working quietly in the background.

Now it becomes clear and understandable that when you type a domain name into your browser, DNS doesn’t guess. It asks the right questions, in the right order, until it reaches the source of truth then delivers the answer back to you.

And that’s how a simple name like kartikeynarayan.in turns into a real website on our screen.

At that moment, a natural question arises in the mind of the end user:

“How does a browser know where a website lives?”

More questions quickly follow.

“How does kartikeynarayan.in turn into a real website on a real server?”
“How does an email sent to contact@kartikeynarayan.in reach the correct inbox?”
“Why does blog.kartikeynarayan.in behave differently from the main website?”

All these questions point to concepts that work quietly in the background. Although everything looks simple on the surface, a lot is happening under the hood. The browser needs a clear set of instructions to find the correct destination.

That entire system of instructions is called DNS (Domain Name System). But in this blog our main focus on DNS record types, a critical concept that helps requests reach the right place, whether it’s opening a website, sending an email, or performing any other action on the internet.

Instructions for the Internet

We can think of DNS as the internet’s phonebook, much like the phonebook we have at home. But there’s a catch. If a phone book has no entries, what’s the point of having it at all? That question makes sense and the same logic applies to DNS.

DNS is useful only because it contains entries, and those entries tell the internet what to do. These entries are known as DNS record types. They act as instructions that guide the internet based on the kind of request being made.

Each record type answers a specific question, such as:

“Who manages this domain?”
“What is the IP address of kartikeynarayan.in?”
“Where should emails for this domain be delivered?”

This is one of the most fundamental and important concepts of DNS. You can think of it as the starting point of the race without it, nothing on the internet knows where to go.

Now, a natural question arises:

“How do we set up DNS records?”

Adding Entries to the Internet’s Phonebook

When you buy a domain name like kartikeynarayan.in from GoDaddy, Hostinger, or any other platform, it doesn’t automatically know where your website or emails should go. At first, it’s like an empty phonebook with a name, but no entries. (In some cases, basic default records are set that point back to the provider’s own DNS.)

To make the domain useful, we need to add entries to it. This process is called setting up DNS records. DNS records live on DNS servers and act as instructions for the internet, telling it where to send website requests, emails, and other services.

By configuring the right DNS records, we teach the internet how to handle different types of requests for our domain whether someone is visiting a website, sending an email, or accessing another service.

At this point, a natural question comes to mind:

“How does this flow work when entries are added to the internet’s phonebook?”

How DNS Finds the Right Place?

Now the story reaches a very interesting point, this is where the real work happens behind the scenes.

To understand how DNS finds the right place, we first need to know about the key entries in the internet’s phonebook. These entries are called DNS record types, and they act as instructions that guide requests across the internet.

The most important DNS records are:

• NS

• A

• AAAA

• CNAME

• MX

• TXT

Each of these records plays a specific role.

A natural question follows:

“How do these records work together to help DNS resolve requests accurately?”

How DNS Records Work Together?

DNS does not rely on a single record to solve everything. Instead, it works like a team, where each DNS record has a specific responsibility. When these records work together, the internet is able to route requests accurately and efficiently.

Let’s understand this with a simple flow.

• When you type a domain name like kartikeynarayan.in into your browser, the internet doesn’t immediately look for the website’s IP address. First, it needs to know who is responsible for managing that domain.

• That responsibility is defined by the NS (Name Server) records. NS records tell the internet which DNS servers are authoritative for the domain and where the correct information can be found.

• Once the correct DNS server is reached, the browser looks for the A or AAAA records. These records provide the actual IP address of the server where the website is hosted, IPv4 for A records and IPv6 for AAAA records.

• Sometimes, a domain doesn’t point directly to an IP address. Instead, it points to another domain name. This is handled by CNAME records, which act like aliases or nicknames. They redirect the request to another domain, which eventually resolves to an A or AAAA record.

• Email delivery works in a similar coordinated way. When an email is sent to an address like contact@kartikeynarayan.in, the sending mail server looks for MX (Mail Exchange) records. These records specify which mail servers should receive emails for the domain.

• Finally, TXT records support the entire system by providing additional information. Most commonly for verification, security, and domain ownership. Technologies like SPF, DKIM, and domain verification rely heavily on TXT records.

Together, these records form a complete instruction set. Each one answers a different question, and only when all of them work together does DNS function smoothly.

It is a well-organized system of responsibilities, decisions, and clear instructions working behind the scenes.

Big Picture

After understanding all the individual DNS records, the bigger picture becomes clear.

DNS records are simply instructions for the internet. They tell it how to find the right place for a request whether that request is coming from a browser, an email server, or another service.

Each record solves a specific problem so there is no confusion:

• NS records define who is responsible for a domain?

• A and AAAA records tell browsers where a website lives.

• CNAME records act like nicknames.

• MX records decide where emails should be delivered.

• TXT records are commonly used for verification and domain ownership checks.

Because every record has a clear responsibility, DNS can resolve requests accurately and efficiently.

Once DNS records start making sense:

“Domains stop feeling magical, they become understandable systems.”

And that’s the moment when DNS truly clicks.

This is exactly what happens on the internet if the data is sent without rules or protocols.

Networks are not always reliable.
Sometimes networks are noisy.
Data packets can be lost, duplicated, or arrive out of order.

So now the big question is:

“How do computers communicate reliably over the network?”

This is where the concept of TCP comes in.

TCP : Reliable Communication with Discipline

Now the real hero comes into the picture:

TCP (Transmission Control Protocol) brings order, reliability, loss detection, retransmission, flow control, and congestion control, making reliable communication possible over an unreliable network.

We can think of TCP as a well-structured conversation, instead of random shouting.

But as developers, we should ask:

“Why is TCP needed at all?”

Let’s find out.

Why is TCP needed at all ?

First, we need to understand how the Internet moves data.

It sends data as small chunks called packets. These packets may take different paths, travel at different speeds, and there is a high chance they can be dropped along the way.

Now here’s the key idea to understand:

TCP does not control the network itself**,** controls the conversation between two computers**.**

Before sending real data, TCP first asks:

“Are you ready?”
“Can you hear me?”
“Am I audible?”

This brings us to the TCP 3-Way Handshake, an important concept in TCP communication.

How Does the 3-Way Handshake Work?

The term “3-Way Handshake” itself is fundamental to TCP.

It may sound simple, but it plays a critical role in TCP communication. Before a client and a server send any data to each other, TCP first makes sure that both computers are ready to communicate. TCP does not control the network, instead, it controls the conversation between the client and the server. Because the Internet is unreliable, both sides need to confirm that they can reach each other, understand each other, and stay in sync.

This preparation step is called the TCP 3-Way Handshake. It ensures that both computers agree to communicate before the actual data transfer begins.

Understanding the 3-Way Handshake with a Simple Analogy

Think of it like this:

Client: “Am I audible?”
Server: “Yes, I can hear you.”
Client: “Great, let’s start.”

Only after this confirmation does real data begin to flow.
Now, let’s deep dive into this flow and understand how it works under the hood.

Step 1: SYN - “Am I Audible?”

The client sends a SYN message.

Meaning:

• “I want to connect with you.”

• “Here is my starting point, Let’s connect.”

At this stage, no actual data is sent, only the intent to communicate.

Step 2: SYN-ACK - “Yes, I Hear You.”

The server replies with a SYN + ACK message.

Meaning:

• “I received your message.”

• “Here is my starting point.”

• “I acknowledge yours.”

At this point, both sides are aware of each other.

Step 3: ACK - “Let’s Begin”

The client sends an ACK message.

Meaning:

• “I acknowledge your response.”

• “We are now synchronized.”

Now, the connection is established between the client and the server, and both sides are ready. Actual data can now flow reliably between them.

Now data is broken into small chunks called segments. Each segment is assigned a sequence number, and the receiver sends acknowledgements (ACKs) for the data it receives. The sender keeps track of what has been sent and what has been acknowledged.

Because of this, TCP always knows:

• What data it has sent?

• What data has been acknowledged?

• What data needs to be retransmitted?

This tracking mechanism is one of the core properties of TCP, and it is what makes reliable data transfer possible.

Does TCP mean “Reliability”?

TCP is associated with reliability, but TCP does not mean reliability by itself. Instead, TCP provides reliability on top of an unreliable Internet. The Internet can lose packets, deliver them out of order, or deliver them multiple times.

TCP handles these problems by using:

• Sequence numbers → to keep data in order.

• Acknowledgements (ACKs) → to confirm delivery.

• Retransmission → to resend lost data.

• Flow control → to avoid overwhelming the receiver.

• Congestion control → to protect the network.

Because of these mechanisms, TCP can guarantee that data is delivered:

• Reliably

• In order

• Without duplication

So, TCP doesn’t just start and end communication politely. it manages the entire lifecycle, from “Am I audible?” to “Bye.”

That is why TCP is considered the reliability layer of the Internet.

What Is “Bye” in Terms of TCP?

People often think that only the start of communication needs rules, but that is only half correct.

For effective communication, both the beginning and the ending need rules. After the data has been transferred and received successfully, the connection should close properly.

TCP closes connections politely and safely using:

• FIN → “I’m done sending data.”

• ACK → “I acknowledge that.”

Both sides agree before disconnecting, which ensures:

• No sudden cuts.

• No half-sent data.

The Full TCP Lifecycle

1. Establish → 3-Way Handshake.

2. Transfer → Reliable, ordered, and error-free data flow.

3. Close → FIN and ACK exchange.

From:

“Am I audible ?”

to

“Bye.”

From the first “Am I Audible?” to the final “Bye”, TCP manages the entire journey of communication.

This chapter goes back to that time to understand why version control wasn’t a luxury, but a necessity.

“This is the story of the Pendrive Problem.”

Before Git, Before Safety

Kartikey still remembers his college days.

No Git.
No GitHub.
No version control.

Just folders and a pendrive.

He had a project directory that looked like this:

to-do-app/
├── final/
├── final_v2/
├── final_v3/
├── final_latest_v1/
├── final_latest_v2/

Each folder meant only one thing:

“Please don’t touch or open the wrong one.”

The Pendrive Workflow

When Kartikey worked with friends, the workflow was simple.

Painfully simple.

• One pendrive.

• One person edits the code.

• The pendrive passes to the next person.

Sometimes, email replaced the pendrive:

“Here’s the updated zip file.”
“No wait, use the newer one.”
“Ignore the last email.”

At that time, Kartikey didn’t think much of it, until things started breaking.

When Code Starts Disappearing?

One day, Kartikey updates a file.
Later, his friend copies an older version from the pendrive.
Kartikey opens the project again.

His changes are gone.

“No warning.”
“No history.”
“No explanation.”

Just… gone.

He asks:

“Who changed this file?”

No one knows.

The Real Problems Appear

Slowly, the real issues become impossible to ignore.

❌ Overwriting Code

Someone saves their version.
someone else’s work disappears.

❌ No History

There’s no way to know:

• What changed?

• Who changed it?

• Why it changed?

❌ No Collaboration

• Only one person can safely work at a time.

• Everyone else waits.

❌ No Going Back

If something breaks:

“Hope someone still has the old file.”

Kartikey realizes something important:

• The problem isn’t bad developers.

• The problem is bad process.

The Folder Timeline Disaster

Kartikey looks at the folder names again.
Each folder is supposed to represent time.

But time is broken.
There’s no clear timeline.

No reliable past.
No safe present.

Just guesses disguised as backups.

Teams Make It Worse

As the team grows, the problem multiplies.

Two people edit the same file.
Three people send updates.
One person forgets to copy the latest version.

Now the project has multiple realities.

Kartikey notices something clearly:
the pendrive workflow doesn’t scale at all.

The Question That Changed Everything

Kartikey asks a simple question:

“Why doesn’t code remember its own history by default?”

Why can’t code:

• Track changes?

• Know who changed what?

• Allow multiple people to work safely?

Why does collaboration feel so fragile?
That’s when Git quietly enters the conversation.

Why Version Control Was Born?

Git explains calmly:

“Pendrives move files.”
“Emails move files.”
“Folders copy files.”
“But none of them understand history.”

Version control was created to solve exactly this:

• Preserve every version.

• Track every change.

• Allow safe collaboration.

• Make mistakes reversible.

Git isn’t about commands.
It is about memory and trust.

Pendrive vs Version Control

Git shows Kartikey the difference.

Pendrive World

• One person at a time.

• No history.

• Easy to lose work.

• Hard to collaborate.

Version Control World

• Everyone works together.

• Full history.

• No lost changes.

• Clear ownership.

Why Git Became Mandatory?

Modern software is:

• Large

• Collaborative

• Long-running

Pendrives and emails were never built for this.

Version control didn’t become popular because it was trendy.
It became mandatory because everything else failed.

Kartikey smiles because now he understands:

“Git didn’t replace pendrives.”
“It replaced uncertainty.”

If you’ve ever lost code, overwritten someone else’s work, or wondered:

“Where did my changes go?”

Version control exists so you never have to feel that again.

Kartikey’s journey continues and this time, the past is finally safe.

“What is Git actually doing behind the scenes?”

This is the story of Kartikey going one level deeper inside Git itself.

“This is where Kartikey’s journey begins.”

The Hidden Door

Kartikey has been using Git for a while now.

He can commit.
He can create branches.
He feels comfortable.

Then one day, while exploring his project folder, he notices something unusual.

A hidden directory.

.git

Kartikey pauses.

“What is this folder… and why does it exist?”

Git doesn’t answer immediately.

The .git Folder Revealed

Finally, Git speaks.

“Everything you trust me for lives here.”

Kartikey opens the .git folder.

It’s not code.
It’s not configuration alone.

It’s Git’s entire memory.

Git explains:

• This folder stores history.

• This folder stores snapshots.

• This folder stores relationships.

• This folder stores integrity.

Then Git adds quietly:

“Delete this folder and I forget everything.”

Kartikey understands.

The .git folder isn’t optional.
It is Git.

Git Doesn’t Track Files

Kartikey assumes Git tracks files line by line.

Git corrects him.

“I don’t track files.”
“I track content.”

Whenever Kartikey writes code, Git doesn’t care about:

• File names

• Folder names

Git only cares about:

• What the content is?

• Whether it has changed?

That’s when Git introduces its core building blocks.

The Three Objects of Git

Git draws three symbols in the air:

• Blob

• Tree

• Commit

“Everything I store is one of these.”

Blob - The Content

A blob is just raw content.

• No filename

• No folder

• Just data

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

Git says calmly:

“I don’t duplicate memory” .

Tree - The Structure

A tree represents:

• Folder structure

• File names

• How blobs are arranged.

Think of a tree as a map, not the content itself.

Commit - The Snapshot

A commit ties everything together.

It points to:

• One tree (structure)

• Previous commit(s)

• Metadata (author, message, time)

Git explains:

“A commit is not a change.”
“It’s a snapshot.”

Kartikey starts seeing Git differently.

What Really Happens During “git add”?

Kartikey types:

git add index.js

Nothing seems to change.

But inside Git, everything changes.

Git explains:

1. Git reads the file content.

2. Git creates a blob.

3. Git calculates a hash.

4. Git stores it inside .git/objects.

5. Git updates the index (staging area).

Git adds:

“The staging area is a list of hashes, I’m preparing to remember.”

Kartikey realizes something important:
git add doesn’t save history, It prepares reality.

What Really Happens During “git commit”?

Now Kartikey commits:

git commit -m "Save progress of index.js file."

Git goes to work.

Internally:

1. Git creates a tree from staged blobs.

2. Git creates a commit object.

3. Git links it to the previous commit.

4. Git moves HEAD forward.

Git says:

“This is when time moves forward.”

Kartikey understands:

Commits don’t store differences.
They store complete snapshots, efficiently.

The Power of Hashes

Kartikey notices strange strings everywhere.

Long.
Random.
Unreadable.

Git explains:

“Those are hashes.”

Every blob, tree, and commit is identified by a cryptographic hash (SHA-1 or SHA-256).

This means:

• Change the content → the hash changes.

• Corrupt the data → the hash does not match.

• History cannot be secretly altered.

Git says calmly:

“My memory is tamper-proof.”

Kartikey finally understands why Git feels so reliable.

The Mental Model Clicks

Git summarizes:

• Files → Blobs

• Folders → Trees

• Snapshots → Commits

• Hashes → Identity

• .git folder → Memory

Git tells Kartikey:

“Don’t memorize commands.”
“Understand how I think.”

That’s when it clicks.

Seeing Git Clearly

Kartikey looks at Git differently now.

Not as magic.
Not as commands.
But as a content-addressed memory system.

He smiles.

Because now:

• Git feels predictable.

• Git feels safe.

• Git feels logical.

And once again, Kartikey realizes:

“Git doesn’t just help him write code.”
“It helps him trust his progress.”

If Git has ever felt mysterious, you’re not alone.
Understanding Git internally doesn’t make you a power user, it makes you a calm developer.

And this is only the beginning of Kartikey’s journey.

This story follows a developer named Kartikey, at the exact moment every beginner reaches when code breaks, panic sets in, and progress feels fragile.

Instead of explaining Git as a list of commands, the story presents it as something else entirely:
A quiet power that protects your work, remembers your journey, and makes mistakes safe.

It’s about realizing that you don’t need to avoid errors to grow.
You just need a way to protect your progress while you make them.

By the end, Git stops feeling confusing and starts feeling like something you can trust.

“This is where Kartikey’s journey begins.”

The Confident Beginning

It’s late evening.

Kartikey’s laptop is open.
VS Code (code editor) glows softly on the screen.

The project finally works.
He leans back and smiles.

“This wasn’t so hard.”

He decides to add one small feature.

Just one more.

No backup.
No copy.

Because why would he need one?

The Moment Everything Breaks

Kartikey saves the file.

He refreshes the browser.
Nothing loads in the browser.

He opens another file.
Change a line in the opened file.

Refresh the browser again.

Now more things are broken.

His heartbeat increases.
He starts undoing randomly:

• Ctrl + Z.

• Reverting files.

• Commenting code like a maniac.

Then the thought hits him:

“I don’t even remember what I changed.”

This is the moment every developer reaches when progress feels fragile and fear takes over.

Someone Was Watching

Kartikey thinks:
He is alone.
He is not.

A calm voice speaks:

“You didn’t lose anything.”

Kartikey looks around.

There’s no one there.
The voice continues:

“I’ve been watching every change you made.”

Kartikey swallows.

“Who are you?”

The answer is simple.

“I am Git.”

Git Explains Itself

Git doesn’t look flashy.

No cape.
No explosions.

Git speaks slowly:

“I don’t stop you from making mistakes.”
“I just make sure mistakes are reversible.”

Git explains:

• It lives on Kartikey’s computer.

• It remembers every meaningful version.

• It creates timelines instead of chaos.

Git isn’t here to control Kartikey.
Git is here to protect his progress.

The Project Transformation

Git points at Kartikey’s project folder.

“Right now, this is just files.”

Git asks Kartikey to type one command:

git init

The air feels different.

Git smiles.

“Now this is a repository.”

Inside your folder:

• A hidden .git directory appears.

• A memory vault is created.

• A timeline engine wakes up.

Kartikey’s project now has a past and a future.

The Three Worlds Revealed

Git draws three circles in the air.

“You think you write code in one place, You don’t.”

The Working Directory

This is where Kartikey writes code.

He experiments.
He breaks things.

Nothing here is permanent.

Git says:

“This world is chaos, and that’s okay.”

The Staging Area

This world is about choice.

“Here, Git explains, you decide what matters.”

Not everything deserves to be remembered.

The Repository

Git lowers its voice.

“Once something reaches here, it becomes history.”

This world never forgets.

Git Notices a Change

Kartikey creates a new file.

He feels proud.
But Git interrupts.

Kartikey asks:

git status

Git replies calmly:

“I see your file.”
“But I’m not tracking it yet.”

Kartikey looks confused.

Git explains:

“I never assume.”
“You must choose.”

The Moment of Decision

Git waits.

Kartikey decides what deserves to be remembered.

git add index.txt

The file moves worlds.
From chaos → preparation.

Git nods.

“Good choice.”

Time is Frozen

Git gives Kartikey one final step.

git commit -m "Initial commit."

Everything stops.

Git speaks softly:

“This moment is safe now.”

A commit is born.

Not a save.
Not a backup.

A checkpoint in time.

The Memory You Didn’t Know You Had

Days pass.

Kartikey commits again and again.

One day, he wonders:

“What have I done so far?”

Git opens a book.

git log

Each page shows:

• What changed?

• Why it changed?

• In what order.

Git remembers Kartikey’s journey better than he ever could.

The Multiverse Decision

Kartikey wants to try something risky.

In the past, this meant fear.

Git shakes its head.

“Create another timeline.”

git checkout -b feature-branch

Reality splits:

Two worlds exist at once.
If one collapses…The other survives.

You Are Never Lost

Git points to a glowing marker.

“This is HEAD - It always shows where you are.”

No matter how complex things get.
Git always knows Kartikey’s position in time.

The Real Power

Kartikey looks at his code again.

It’s not perfect.
But he’s calm.

Because now he knows:

• Mistakes aren’t disasters.

• Experiments aren’t dangerous.

• Progress is never lost.

Git doesn’t make Kartikey smarter.
Git makes him braver.

And that’s when he realizes:

“He is not just writing code anymore.”
“He is controlling time.”

If this story felt familiar, you’re not alone.
Every developer reaches this moment.

The difference is whether you have a way to protect your progress when you do.

And this is only the beginning for Kartikey.