Usually your browser does the asking for you. But what if you want to ask a server directly, without a browser, and see exactly what comes back? That’s what cURL is for, and by the end of this blog you’ll have used it yourself.

What is cURL?

cURL is a command-line tool that sends a message to a server and shows you the reply. That’s it.

Think of it as sending a text message to a server from your terminal. You type the address, hit Enter, and the server texts back.

Why Do Programmers Need cURL?

When you build a backend or work with APIs, you constantly need to check things. Is my server running? What does this API return? Did my change work?

A browser can do some of this, but cURL is faster, scriptable, and shows you the raw conversation. It’s like a test drive for your server, with no fancy app in the way.

Your First Request

Open your terminal and type:

curl https://example.com

Press Enter. You’ll see a block of text that starts with <!doctype html>. That’s the actual webpage code, the same thing your browser receives before turning it into a pretty page.

Congratulations, you just talked to a server.

Understanding Request and Response

Every conversation has two parts.

Request: what you send. It says which address you want and what you want to do with it.

Response: what the server sends back. It has two important parts:

1. Status code: a number telling you how it went. 200 means success, 404 means not found, and 500 means the server had a problem.

2. Body: the actual data, like a webpage or some JSON.

Want to see the status? Add -i to include the response details:

curl -i https://example.com

You’ll see a line like HTTP/2 200 at the top, then some headers (extra info about the response), then the body.

Think of status codes like a restaurant. 200 is “here’s your food,” 404 is “we don’t have that dish,” and 500 is “the kitchen is on fire.”

Using cURL to Talk to APIs

An API is a server that returns data instead of webpages, usually as JSON. Here’s a free practice API:

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

You’ll get back something like:

{
  "userId": 1,
  "id": 1,
  "title": "...",
  "body": "..."
}

That was a GET request, which means “give me this data.” It’s the default, so you didn’t have to type anything extra.

The other one you’ll meet early is POST, which means “here’s some data, please save it”:

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

Here, -X POST sets the method, -H adds a header saying we’re sending JSON, and -d is the data. The server replies with the created item.

For now, remember only this: GET is for reading, POST is for sending.

Common Mistakes Beginners Make

1. Forgetting https://. Always include the full address, or cURL may not behave as you expect.

2. Messing up quotes in POST data. JSON needs double quotes inside, so wrap the whole thing in single quotes (on Windows PowerShell, quoting works differently, so be careful).

3. Forgetting the Content-Type header when sending JSON. The server may not understand your data.

4. Panicking at the wall of text. It’s normal. Look for the status code first, then the body.

5. Ignoring the status code. A 404 or 500 tells you what went wrong before you read anything else.

Wrapping Up

cURL is just a way to talk to servers from your terminal. Send a request, read the response, and check the status code. GET reads, POST sends. Start there, and everything else will make sense later.

So the internet runs on protocols, which are sets of rules for how data is sent. In this blog we’ll look at two main ways to send data (TCP and UDP), and then clear up one of the most common beginner confusions: how HTTP fits in.

What are TCP and UDP?

Both are transport protocols. Their job is to carry data from one computer to another. They just do it in very different ways.

TCP is safe and reliable. It makes sure everything arrives, in order, and correctly.

UDP is fast but risky. It sends data and doesn’t check if it arrived.

The Analogies

TCP is a phone call. You dial, the other person picks up, you confirm you can hear each other, and you talk. If you miss something, you say “sorry, can you repeat that?” Nothing is lost.

UDP is a public announcement. The speaker just talks into the microphone. If you were in the toilet and missed it, too bad. Nobody repeats it.

Another way to see it: TCP is a courier who gets your signature on delivery, while UDP is a live broadcast that keeps going whether or not you’re watching.

Key Differences

1. Connection: TCP sets up a connection first (the handshake). UDP just starts sending.

2. Reliability: TCP resends lost data. UDP doesn’t.

3. Order: TCP delivers data in the correct order. UDP may arrive jumbled.

4. Speed: UDP is faster because it skips all the checking. TCP is slower because of the extra work.

5. Overhead: TCP carries more bookkeeping. UDP is lightweight.

In short: TCP trades speed for safety, and UDP trades safety for speed.

When to Use TCP

Use TCP when every piece of data matters. If something is missing, the whole thing breaks.

Websites, email, file downloads, and banking are all good examples. Imagine a webpage with missing chunks of code, or a bank transfer where half the message vanished. Nobody wants that.

When to Use UDP

Use UDP when speed matters more than perfection, and a small loss is acceptable.

Live video calls, online games, and live streaming are the classic examples. If one frame drops in a video call, you barely notice. But if the call paused to resend an old frame, you’d get awkward lag. In a game, the player’s position from half a second ago is useless, so there’s no point resending it.

DNS lookups also typically use UDP, because the questions and answers are tiny and fast.

What is HTTP?

Now for the confusing part. You’ve probably heard of HTTP, the protocol behind every website. But is it the same as TCP?

No. HTTP is an application-level protocol. It defines what the browser and server say to each other: “GET me this page,” “here’s the page, status 200,” and so on. It’s about the message and its meaning.

TCP is a transport protocol. It decides how those messages travel safely across the network.

HTTP Runs on Top of TCP

Think of them as layers, stacked like this:

Think of sending a letter. HTTP is the letter you write. TCP is the registered post service that makes sure it arrives. They’re different things, and you need both.

How an HTTP Request Flows Over TCP

When you open a website:

1. Your browser opens a TCP connection to the server (the handshake).

2. It sends an HTTP request through that connection.

3. The server sends back an HTTP response, also through that connection.

4. TCP makes sure all the pieces arrive intact and in order.

Why HTTP Doesn’t Replace TCP

HTTP has no idea how to handle lost packets, ordering, or retransmission. That’s TCP’s whole job. HTTP simply assumes that whatever it sends will arrive safely, because TCP is quietly working underneath.

So when someone asks, “Is HTTP the same as TCP?”, the answer is: no, HTTP runs on top of TCP. (One small note for later: newer versions of HTTP, like HTTP/3, actually run over a UDP-based protocol called QUIC, but for now, “HTTP runs on TCP” is the right mental model.)

Wrapping Up

The internet needs rules, and these are three of the big ones. TCP is a careful phone call that guarantees delivery. UDP is a fast announcement that doesn’t look back. HTTP is the language websites speak, riding on top of TCP.

Pick TCP when accuracy matters, UDP when speed matters, and remember that HTTP and TCP are partners, not the same thing.

That’s what sending data over a network looks like without rules. TCP is the set of rules that fixes it. This blog is for beginners, so we’ll keep it simple and skip packet-level details.

What is TCP and Why Do We Need It?

TCP (Transmission Control Protocol) is a protocol that makes sure data gets from one computer to another reliably, in order, and without damage.

Networks are messy. The internet is made of many devices passing little chunks of data (called packets) along different routes. Things go wrong, and TCP is the system that handles it, so your web pages, emails, and downloads arrive intact.

Problems TCP Solves

When data travels over a network, four things can go wrong:

1. Lost packets: some pieces never arrive.

2. Out-of-order packets: pieces arrive in a different order than they were sent.

3. Duplicate packets: the same piece arrives twice.

4. Corrupted packets: a piece arrives damaged.

TCP detects each of these and fixes them automatically, so the application on top (your browser, for example) never has to worry.

The 3-Way Handshake: Saying Hello Properly

Before sending any real data, TCP makes sure both sides are ready. It does this with a three-step greeting called the 3-way handshake.

Think of a phone call:

Step 1 (SYN): You call and say, “Hi, can you hear me?”

Step 2 (SYN-ACK): They answer, “Yes, I can hear you. Can you hear me?”

Step 3 (ACK): You say, “Yes, I can. Let’s talk.”

Now both sides know the line works in both directions.

In TCP terms:

1. SYN (synchronize): The client says, “I want to connect, and I’ll start counting my data from number X.”

2. SYN-ACK: The server says, “Got it. I’m ready too, and I’ll start counting from number Y.”

3. ACK (acknowledge): The client says, “Got yours too. Connection open.”

Those starting numbers are called sequence numbers, and they’re the key to everything that follows.

How Data Transfer Works

Once connected, TCP breaks your data into small pieces and gives each one a sequence number, like page numbers in a letter. The receiver sends back acknowledgements (ACKs) saying, “I got everything up to here.”

Sequence numbers let the receiver put pieces back in the right order, even if they arrive jumbled, and spot duplicates and throw them away.

How TCP Ensures Reliability

Packet loss and retransmission: What if a piece goes missing? The sender waits for an ACK. If it doesn’t arrive within a short time, the sender assumes the piece was lost and sends it again. This is called retransmission.

Correctness: Each piece also carries a small check value (a checksum). If the data arrives damaged, the receiver notices and discards it, and the missing ACK triggers a resend.

Flow control: TCP also stops a fast sender from overwhelming a slow receiver, so it adjusts its speed to what the other side can handle.

Together, these give us reliability (nothing lost), order (correct sequence), and correctness (nothing damaged).

How a TCP Connection is Closed

When both sides are done, they say goodbye politely, again using a conversation:

1. FIN: One side says, “I’m finished sending.”

2. ACK: The other side replies, “Got it.”

3. FIN: The other side says, “I’m finished too.”

4. ACK: The first side confirms, “Okay, bye.”

Closing takes four steps because each direction of the connection is closed separately.

Why This Matters for Developers

Almost everything you build on the web, including HTTP requests, APIs, and database connections, runs on top of TCP. When you see a “connection timeout” or “connection refused” error, the handshake is where things went wrong. And when a site feels slow, retransmissions caused by a bad network may be the reason.

Wrapping Up

TCP is a polite, careful conversation between two computers. They greet each other (3-way handshake), exchange numbered pieces and confirm each one (data transfer), resend anything lost (reliability), and say goodbye properly (connection close).

You type a name like mysite.com, and a moment later the page appears. But computers don’t understand names, they understand numbers. Somewhere in between, something looks up the name and finds the right place.

That something is DNS, and the details live in small entries called DNS records. Don’t worry, there are only a handful you need to know, and we’ll take them one at a time.

What is DNS?

DNS is the phonebook of the internet. You look up a name, and it gives you the number. You remember mysite.com, and DNS finds the address behind it.

Why Do We Need DNS Records?

A phonebook entry doesn’t just hold a number. Some entries hold an address, a work number, or an email. DNS works the same way. A domain needs to answer different questions: Where is the website? Who manages this domain? Where should emails go?

Each question is answered by a different record type. Let’s meet them.

NS Record: Who’s in Charge?

An NS (Name Server) record says which servers are responsible for your domain’s records. Think of it as the post office that handles all mail for your street. When anyone asks about your domain, they’re sent there first.

When you buy a domain and point it to a hosting or DNS provider, you’re setting its NS records.

A Record: Domain → IPv4 Address

An A record connects a name to an IPv4 address (like 192.0.2.10). It’s the house address of your website.

mysite.com    A    76.76.1.1

This solves the most basic problem: “where is the server for this name?”

AAAA Record: Domain → IPv6 Address

Same job as an A record, but for the newer IPv6 format (like 2001:db8::1). The world was running out of IPv4 addresses, so IPv6 was created. Many sites keep both records so every visitor can connect.

CNAME Record: One Name Pointing to Another

A CNAME says “this name is just another name for that one.”

www.mysite.com    CNAME    mysite.com

Think of it as a nickname. If you call someone “Hardik” and Hardy,” both lead to the same person. The big benefit is that if the real address changes, you only update one record and every nickname follows.

A vs CNAME, gently cleared up: An A record points a name to an IP address. A CNAME points a name to another name. If you know the IP, use A. If you want one name to follow another, use CNAME. One handy rule: a CNAME can’t normally sit on the bare root domain (mysite.com), so root domains use A records.

MX Record: Where Does Email Go?

When someone emails hello@mysite.com, how does the message find your mail server? Through MX (Mail Exchange) records, which tell the world which servers accept email for your domain.

mysite.com  MX  10  mail.mysite.com

The number is a priority, and lower numbers are tried first. It’s like a mailbox address that’s separate from your house. Your website and your email can live in completely different places.

NS vs MX, gently cleared up: NS says who manages the domain’s records. MX says where emails should be delivered. One handles control, the other handles mail.

TXT Record: Extra Information

A TXT record holds plain text notes about your domain. It’s mostly used for verification and email security, like proving to a service that you own the domain, or setting email rules (SPF, DKIM) so your emails don’t land in spam.

mysite.com    TXT    "verification-code-abc123"

Think of it as a sticky note on your door that others can read to confirm it’s really yours.

How They Work Together

Here’s one small website with everything in place:

mysite.com        NS       ns1.dnsprovider.com
mysite.com        A        76.76.1.1
mysite.com        AAAA     2001:db8::1
www.mysite.com    CNAME    mysite.com
mysite.com        MX       10 mail.mysite.com
mysite.com        TXT      "verification-code-abc123"

Visitors use A and AAAA to find the site. www follows along through the CNAME. Emails use MX to reach your inbox. Services use TXT to verify you. And NS makes sure everyone asks the right place.

Wrapping Up

NS says who’s in charge. A and AAAA say where the site lives. CNAME gives a name a nickname. MX handles email. TXT holds notes and proof. Six small records, and together they run your domain.

Computers don’t understand names. They understand IP addresses like 142.250.x.x. DNS is the system that translates one into the other, and in this blog we’ll watch it work, live, using a tool called dig.

What is DNS and Why Does It Exist?

DNS (Domain Name System) is the internet’s phonebook. You remember names, but computers need numbers. DNS looks up the name and returns the number.

Imagine if you had to memorize an IP address for every website you use. DNS exists so you never have to.

What is dig?

dig is a command-line tool that lets you ask DNS questions and see the raw answers. Developers use it to debug problems like “my domain isn’t loading” or “I changed my DNS settings, did it work?”

Think of it as a flashlight for DNS: normally the whole process is invisible, and dig lets you see inside.

DNS Works in Layers

No single server knows every website. Instead, DNS is a hierarchy with three levels:

Root → TLD → Authoritative

Each level only knows who to ask next. It’s like asking for directions: the first person says “go to that town,” the next says “go to that street,” and the last one points at the exact house.

Let’s walk through each layer with dig.

Layer 1: Root Name Servers (dig . NS)

dig . NS

The single dot . represents the root of the internet. This command asks, “Who are the root name servers?”

The answer is a list of 13 named servers, a.root-servers.net through m.root-servers.net. (Each name is backed by many machines around the world, so there are far more than 13 physical servers.)

NS records (Name Server records) simply say “these servers are responsible for this zone.” That’s what you’re seeing here.

The root servers don’t know where google.com is. They only know who handles .com, .org, .net, and the rest.

Layer 2: TLD Name Servers (dig com NS)

dig com NS

TLD stands for Top-Level Domain, like .com. This command asks, “Who manages everything ending in .com?”

You’ll get servers like a.gtld-servers.net. These servers don’t know google.com’s IP either, but they know which servers are in charge of google.com.

Layer 3: Authoritative Name Servers (dig google.com NS)

dig google.com NS

Now we’re at the last level. The answer lists servers like ns1.google.com through ns4.google.com. These are the authoritative servers, the ones Google itself controls. They hold the real, final answer.

This is why NS records matter: when you buy a domain and point it to a hosting provider, you’re setting its NS records, telling the world who is in charge of your domain.

The Full Flow (dig google.com)

dig google.com

Now we ask the real question. In the output, look at the ANSWER SECTION. You’ll see an A record: google.com and its IP address. Next to it is a number called TTL (time to live), which tells caches how many seconds they can remember this answer.

But how did we get that answer without visiting each server by hand? That’s the job of the recursive resolver.

The Recursive Resolver: Your Personal Assistant

When your browser needs an IP, it asks a recursive resolver (usually run by your ISP, or something like 8.8.8.8). The resolver does all the legwork:

1. Asks a root server: “Where is google.com?” → “Ask the .com servers.”

2. Asks a TLD server: “Where is google.com?” → “Ask ns1.google.com.”

3. Asks the authoritative server: “Where is google.com?” → “Here’s the IP.”

4. Returns the answer to your browser and caches it for the TTL.

Because of caching, most lookups skip these steps entirely and finish in milliseconds.

Connecting It to Your Browser

Here’s the real-world order of events when you open a website:

1. The browser checks its own cache.

2. If it’s not there, it asks the recursive resolver.

3. The resolver finds the IP through root → TLD → authoritative (or its cache).

4. The browser connects to that IP and loads the page.

DNS is step zero of every request. If it fails, nothing else happens, which is why “DNS issue” is a classic cause of “the site is down.”

Why This Matters for Engineers

Once you understand DNS, many mysteries get easier: why changes to your domain take time to spread (caching and TTL), why a site works on one network but not another (different resolvers), and why DNS providers are such a critical part of system design.

Wrapping Up

DNS translates names into IPs through layers: root points to TLD, TLD points to authoritative, and the authoritative server gives the final answer. The recursive resolver does the work for you, and dig lets you watch it happen.

Behind that one click, your request passes through a chain of devices: a modem, a router, a switch, a firewall, and maybe a load balancer. As a software engineer, you don’t need to configure them, but you do need to know what they do. When your app is slow or unreachable, this is where the answers are.

This blog is for beginners. We’ll go one device at a time, with one job each.

The Big Picture

Your internet journey looks like this:

Internet → Modem → Router → Switch → Your devices

Now let’s meet each one.

Modem: The Translator

Your internet provider sends data through cables or fiber, in a signal format your laptop can’t understand. The modem translates that signal into digital data your devices can use, and back again.

Analogy: the modem is the front door of your house. It’s the only way the outside world gets in. Without it, you have no internet at all.

Router: The Traffic Police

The modem brings the internet in, but who decides which device gets which data? That’s the router.

It gives every device a local IP address, sends the right data to the right device, and forwards your requests out to the internet. It also connects separate networks together, such as your home network and the internet.

Analogy: a traffic police officer at a crossroads, pointing every vehicle in the right direction.

Modem vs Router: The modem connects you to the internet. The router shares that connection among your devices and directs traffic. Many home boxes combine both, which is why people confuse them.

Hub vs Switch: How Local Networks Work

Now you have a router, but what if an office has 50 computers? You plug them all into a device that links them together. There are two types.

Hub: A hub is simple and not very smart. When it receives data, it sends it to every connected device. Everyone gets everything, even if it wasn’t meant for them. That wastes bandwidth and is a security risk.

Switch: A switch is smarter. It learns which device sits on which port (using MAC addresses) and sends data only to the intended device.

Analogy: a hub is a teacher shouting a message to the whole class. A switch is a teacher passing a note to one student. That’s why switches replaced hubs almost everywhere.

Firewall: The Security Gate

Not everything coming through your network is friendly. A firewall watches traffic and follows rules: allow this, block that.

For example, it can allow web traffic on port 443 and block everything else. It protects your network from unwanted access, and it can also stop your own systems from sending data where they shouldn’t.

Analogy: a security guard at a gate checking everyone’s ID before letting them in. This is where security lives, and when you hear about “opening a port” on a server, a firewall rule is usually involved.

Load Balancer: The Toll Booth Manager

Imagine your app goes viral and 100,000 users arrive at once. One server can’t handle that. So you run multiple servers, but how do users know which one to hit?

A load balancer sits in front of your servers and spreads incoming requests across them. If one server crashes, it stops sending traffic there, so users never notice.

Analogy: a toll plaza with many booths. The manager directs each car to the shortest line. This is why scalable systems need load balancers: they add capacity and reliability at the same time.

How They Work Together

Here’s a real web app setup, in order:

1. A user sends a request from their phone.

2. It travels over the internet to your company’s network.

3. The firewall checks if the request is allowed.

4. The load balancer picks a healthy server.

5. The router and switch deliver it inside the network to that server.

6. The server processes the request and sends the response back the same way.

In real cloud deployments, these exist as virtual services (security groups, virtual routers, managed load balancers), but the jobs are the same.

Why This Matters for Backend Engineers

When you deploy code, you’re deploying into this world. Once you know it, errors stop being scary:

A “connection timed out” error might be a firewall blocking your port. A server that’s down but your site still works? The load balancer is routing around it. An app that works locally but not in production? Networking is the first thing to check.

Wrapping Up

Modem brings the internet in. Router directs traffic. Switch connects local devices smartly. Firewall guards the gate. Load balancer shares the work. Remember those five jobs and you’ll understand how any system gets from your keyboard to your users.

Git exists so this never happens to you. This blog is for complete beginners, and by the end you’ll know what Git is, why developers swear by it, and the commands you’ll use every single day.

What is Git?

Git is a distributed version control system. In simple words, it’s a tool that remembers every version of your project, so you can go back to any earlier point in time.

“Distributed” means every developer has a full copy of the project and its history on their own computer. You don’t need the internet to save your work, and if one computer dies, the project still lives on the others.

Why Git is Used

Developers use Git for three big reasons:

1. Safety: You can always go back to a version that worked.

2. Teamwork: Many people can work on the same project without overwriting each other.

3. History: You can see who changed what, and why.

Think of it as a “save point” in a video game. You don’t replay the whole game when you die. You just reload.

Core Terminologies

Before the commands, here are four words you’ll hear constantly.

Repository (repo): Your project folder plus all of its saved history.

Commit: A saved snapshot of your project at a moment in time, with a message describing what changed.

Branch: A separate line of work. You can try a new feature on a branch without touching your main code. The default is usually called main.

HEAD: A pointer that says where you are right now, usually the latest commit of your current branch.

The Three Areas of Git

This is the most important idea to understand. Your files move through three places:

1. Working directory: where you edit your files.

2. Staging area: where you pick which changes go into the next commit.

3. Repository: where the committed snapshots are stored permanently.

Staging is like packing a box before shipping. You choose what goes in, then you seal it with a commit.

Essential Git Commands

Let’s use them on a real project.

1. git init starts Git in your folder.

git init

2. git status shows what’s changed, what’s staged, and what’s untouched. Use it all the time.

git status

3. git add moves changes into the staging area.

git add index.html
git add .

The second one stages everything.

4. git commit saves the staged changes with a message.

git commit -m "Add homepage"

5. git log shows your commit history.

git log 

6. git revert

Undoes a commit safely by creating a new commit that cancels out the old one. Your history stays intact, so it’s the right choice for work you’ve already shared.

git log --oneline
# a1b2c3d Add login validation
# e4f5a6b Fix password bug

git revert a1b2c3d

Use the short code (hash) from git log --oneline to pick the commit you want to undo.

Under the hood, nothing is erased. Git just adds one more commit object on top of the chain, one whose snapshot undoes the old change.

7. git reset --hard

Moves your project back to an older commit and deletes everything after it, including any uncommitted changes in your files.

git reset --hard e4f5a6b

Be careful : The commits after that point disappear from your history, and uncommitted work is gone for good. Never use it on commits you’ve already pushed and shared with others.

Two more you’ll need soon : git branch lists your branches, and git clone <url> copies an existing repository to your computer.

A Basic Workflow From Scratch

Here’s the whole thing together:

mkdir my-project
cd my-project
git init
echo "Hello Git" > hello.txt
git status
git add hello.txt
git commit -m "Add hello file"
git log --oneline

Now change the file, run git status again, and repeat add and commit. Each loop creates a new commit, and your history grows like a chain.

The loop is simple: edit, status, add, commit. Do it a few times and it becomes muscle memory.

Wrapping Up

Git isn’t scary. It’s the save button your projects always needed. Master the three areas and the seven commands above, and you’re ready for real projects. Start small, commit often, and never lose your work again.

Then one day something breaks, and you realize you have no idea what Git is actually doing. If that’s you, this blog is for you. We’ll skip the memorizing and build a mental model instead.

The .git Folder: Git’s Brain

Run git init in any project and Git quietly creates a hidden folder called .git. This folder is your repository. Your project files are just the visible part. Everything Git knows, including history, branches, and commits, lives inside .git.

That’s also why deleting it makes your project forget all its history, and why copying it to another machine copies the whole repository.

Here are the key parts:

1. objects/ sthores all your content (files, folders, commits).

2. refs/ stores branch names and where they point.

3. HEAD tells Git which branch you’re currently on.

4. index is the staging area, the waiting room for your next commit.

Git Objects: Blob, Tree, Commit

Git is basically a database made of three simple object types.

Blob stores the contents of a file. Only the content. It doesn’t even know the filename.

Tree is like a folder. It lists which blobs and other trees belong together, along with their filenames.

Commit is a snapshot. It points to one tree (the project at that moment), stores the author, message, and time, and points to its parent commit. That chain of parents is your history.

Think of it like a photo album. Blobs are the raw photos, trees are the pages that arrange them, and a commit is the album’s label saying “this is how it looked on Monday.”

Hashes: How Git Keeps Things Honest

Every object gets a name, which is a hash. It’s a long string like a3f5c9..., calculated from the object’s content. This gives Git two superpowers:

1. Same content always gives the same hash, so Git never stores duplicates.

2. Change even one character and the hash changes completely. If a file gets corrupted or tampered with, Git notices.

A commit’s hash also depends on its parent’s hash, so you can’t quietly rewrite history without everything after it changing too. That’s how Git guarantees integrity.

What Happens During git add and git commit

Now the fun part. Let’s say you edit index.html and run these:

git add index.html
git commit -m "Update homepage"

On git add: Git reads the file, calculates its hash, and saves its content as a blob inside .git/objects. Then it updates the index (staging area) to say, “this filename now points to this blob.”

On git commit: Git turns the staging area into a tree object, creates a commit object that points to that tree and to the previous commit, and then moves your current branch forward to the new commit.

That’s it. Nothing is copied around or overwritten. Git just adds new objects and moves a pointer.

How Git Tracks Changes

Here’s the part that surprises most people. Git doesn’t store “changes.” It stores snapshots. When you view a diff, Git is comparing two snapshots on the spot. And since unchanged files reuse the same blob, snapshots stay small and fast.

Wrapping Up

Once you see Git as blobs, trees, commits, and pointers, commands stop feeling like spells. git add makes blobs, git commit makes trees and commits, and branches are just labels pointing to commits.

Then Rahul calls: “Bro, did you use my latest file? I fixed a bug last night.”

Silence. You check, and you used the old one. Your own changes from this morning are gone too, because you pasted his files right over yours.

If you’re new to programming, this blog is for you. It explains why this nightmare is the reason version control exists.

The Pendrive Workflow

Before tools like Git, sharing code meant pendrives, emails, and USB cables. Folders looked like this:

project_final
project_final_v2
project_final_v2_latest
project_final_v2_latest_REAL
project_final_v2_latest_REAL_dontTouch

Nobody could say which one was actually the latest. Everyone had their own copy, and every copy was slightly different.

Overwriting Code

Say you and Rahul both edit login.js. You add form validation, and he fixes a bug in the password check. You each save your own copy. When you finally combine them, whoever copies last wins, and the other person’s work vanishes silently. No warning appears and no error shows up. You only find out when something breaks.

Losing Changes

Overwriting isn’t the only way to lose work. A pendrive gets corrupted. An email gets buried. You delete a function at 1 AM because it “looks useless,” save the file, and realize three days later that you needed it. Without a saved history, there is no undo button for yesterday. Whatever is gone stays gone.

No Collaboration History

Even when nothing was lost, one question had no answer: who changed this, and why?

Suppose the app crashes after a team update. You open the code and find a strange line. Who wrote it? When? What was it replacing? With pendrives and folders, nobody knows. You end up asking the whole team on WhatsApp, and everybody says, “Not me.”

Why This Breaks Real Teams

With two people, this is annoying. With ten, it’s chaos. Add up the problems:

1. Nobody knows which file is the latest.

2. Two people’s work collides and one gets erased.

3. Mistakes can’t be undone.

4. There is no record of who changed what.

Real software has thousands of files and many developers working at the same time. Sharing by pendrive doesn’t scale. Teams were losing hours, and sometimes weeks, to the same avoidable mistakes.

Enter Version Control

Developers needed one shared place for the code, a record of every change, and a safe way to combine everyone’s work. That is exactly what a Version Control System (VCS) provides. Instead of copying files around, you:

1. Keep the project in one central place (a repository).

2. Save changes as small checkpoints called commits, each with a note on what changed and who made it.

3. Go back to any older version whenever you want.

4. Merge multiple people’s work without silently erasing anyone’s.

It’s like having a “save point” in a video game. If you mess up, you reload instead of starting over.

Why It Became Mandatory

Today, no serious team writes code without version control. It protects your work, shows the full history, and lets many people build the same project together. Companies expect it, and so should you.

So the next time you see a folder named final_v2_latest_REAL, you’ll know that is the problem Git was built to solve.