It didn’t load.

He refreshed.
Same result.

Chrome showed:

DNS_PROBE_FINISHED_NXDOMAIN

One of those errors that looks serious but explains nothing.

He double-checked the spelling.
Internet was fine.
Other sites worked.

So why this one?

That’s when Shug realised something obvious, but late.

Browsers don’t understand website names.
They understand numbers.

You type example.com.
The browser needs something like 93.184.216.34.

Somewhere in between, that translation has to happen.

That system is DNS.

DNS, without the complicated talk

DNS is basically the phonebook of the internet.

You remember names.
The internet needs addresses.

Same way you save “Hitesh sir” in your phone instead of memorising his number.

DNS takes a name and finds the correct address behind it.

Simple idea.
Lots of small moving parts.

Why DNS has so many records

When Shug opened DNS settings, he expected one field.

Instead, he saw a list:
A, AAAA, CNAME, MX, TXT, NS.

It felt messy, but it isn’t.

Each record answers a different question.

Not everything at once.
One question at a time.

NS record : who’s allowed to answer?

Before anything else, the internet asks:

“Who is responsible for this domain?”

That answer comes from the NS record.

It points to the DNS servers that are in charge of the domain.

When Shug connected his domain to Cloudflare, the NS record told the rest of the internet:

“Ask Cloudflare about this one.”

No NS record means no authority.
No authority means nothing works.

A record : where the website lives

Once authority is clear, the next question is simple:

“Where is the website?”

That’s the A record.

It maps a domain name to an IPv4 address.

example.com → 93.184.216.34

Think of it like this:

• Domain name is the place name

• IP address is the exact location

Without an A record, the browser knows what you typed, but not where to go.

AAAA record : same idea, newer address

The AAAA record does the same job as A.

The only difference:

• A → IPv4

• AAAA → IPv6

IPv6 exists because the internet ran out of IPv4 addresses.

If your hosting supports it, you’ll see AAAA.
If not, A still works fine.

No extra philosophy needed.

CNAME — one name pointing to another

This one confused Shug the first time.

A CNAME does not point to an IP address.

It points to another domain name.

Example:

www.example.com → example.com

So when someone opens www.example.com, DNS quietly redirects the question to the main domain.

It’s useful for keeping things flexible.

One rule Shug learned the hard way:

• A record → IP address

• CNAME → domain name

Mixing them for the same hostname causes problems.

MX record : why email broke

The website came back.

Emails didn’t.

That’s because email doesn’t use A records.

It uses MX records.

When someone sends mail to hello@example.com, the internet asks:

“Which mail server should handle this?”

MX records answer that.

This is why:

• Website hosting and email hosting are separate

• Your site can be on one service and email on another

DNS keeps them organised.

TXT records : proof, not routing

TXT records look unimportant.

They aren’t.

They’re mostly used for verification:

• Proving domain ownership

• Email security checks

• Service integrations

They don’t send traffic anywhere.
They just respond when something asks, “Is this legit?”

After breaking email verification once, Shug stopped deleting them.

How it all works together

For one normal website:

• NS decides who’s in charge

• A / AAAA decides where the site lives

• CNAME handles extra names

• MX routes email

• TXT proves ownership and trust

Each record solves one small problem.

Together, they make the site work.

Final thought

DNS feels confusing until you stop treating it like theory.

Once Shug looked at it as:

“What question is this record answering?”

Everything made sense.

The site loaded.
Emails started coming in.

Shug finally made chai.

And promised himself not to touch DNS casually again. ☕

shug has been using git for weeks.

git add. git commit. git push.

commands work. project is safe.

but never looked inside .git folder.

uncle mentioned it once: "that's where git keeps everything"

today is the day.

enable hidden files

shug goes to folder settings.

clicks "show hidden files"

waits.

.git folder appears.

shug stares at it.

double clicks.

folder opens.

dramatic music plays in head 🎵

what lives inside

.git/
├── HEAD
├── config
├── objects/
├── refs/
│   ├── heads/
│   └── tags/
└── ...more stuff

shug blinks.

weird file names. folders with cryptic names.

no .html. no .css. no normal files.

this is git's brain.

the objects folder (memory vault)

.git/objects/

shug clicks into it.

hundreds of folders.

each has 2-character names: a1/, f3/, 9e/...

inside each folder: more weird files with long names.

no file extensions.

shug tries to open one in text editor.

��x�K��OR04f�I��Q����+�...

gibberish.

closes it quickly.

(feels like opened something not meant for humans)

uncle's voice in head: "objects folder stores everything"

okay but... everything as what?

shug googles: "git objects folder"

article says: "each file is a git object with SHA-1 hash"

shug: "what's a shaw-one"

more googling.

oh. it's SHA-1. like S-H-A.

hash = fingerprint for data.

same data = same hash.

different data = different hash.

so this folder stores:

• every file shug ever committed

• every commit message

• every version of every file

all compressed into these weird binary files.

shug stares.

this is git's actual memory.

the brain.

the vault.

everything is here.

nothing is ever truly deleted.

shug feels weird about it.

my entire project history is in this one folder?

checks folder size: 4.2 MB

project is 50 MB.

how?

git compression magic.

(uncle will explain later)

for now shug just knows:

.git/objects/ = where git remembers everything.

touch this folder = break git.

respect this folder = git respects you.

shug closes it gently.

like closing someone's diary.

reading a commit object

okay but can shug actually read these things?

googles again: "how to read git objects"

finds command: git cat-file

uncle mentioned this once.

time to try.

first: get a commit hash.

git log --oneline

output:

a1b2c3d updated heading
e4f5g6h fixed typo
7h8i9j0 initial commit

okay. a1b2c3d is latest commit.

now the scary command:

git cat-file -p a1b2c3d

shug hits enter.

holds breath.

output:

tree 4f8e9a1
parent e4f5g6h
author shug <shug@email.com>
committer shug <shug@email.com>
date: Mon Jan 8 14:23:11 2024

updated heading

shug stares.

it worked?

it just... showed the commit?

reads it again.

commit has structure:

• tree 4f8e9a1 → project snapshot at this moment

• parent e4f5g6h → previous commit (the one before this)

• author → who made it (me)

• committer → who committed it (also me)

• date → when

• updated heading → commit message (why)

shug tries something.

what if checks the parent commit?

git cat-file -p e4f5g6h

output:

tree 2c3d4e5
parent 7h8i9j0
author shug <shug@email.com>

fixed typo

it has a parent too.

which also has a parent.

wait.

it's a chain.

shug's brain clicks.

every commit points to its parent.

git follows these pointers backward.

that's how git log works.

that's how history exists.

mind blown. 🤯

sits back in chair.

stares at ceiling.

git isn't magic.

it's just... linked data.

like a playlist where each song remembers the previous song.

tries one more thing:

git cat-file -p 4f8e9a1

(that's the tree hash from first commit)

output:

100644 blob 8ab3f21    index.html
100644 blob f39d8e2    style.css
040000 tree a84d9c1    images/

the tree shows files in that commit.

each file has its own hash (blob).

shug checks a blob:

git cat-file -p 8ab3f21

output:

<!DOCTYPE html>
<html>
  <head>
    <title>shug's project</title>

it's the actual file content.

shug leans back.

closes laptop.

needs a moment.

the whole system just made sense:

1. you commit → git creates snapshot

2. snapshot = tree object listing all files

3. each file = blob object with content

4. commit points to tree + parent commit

5. git walks these links for history

opens laptop again.

one more test.

creates new file. commits it.

checks .git/objects/ folder.

new folders appeared.

new hashes.

for new commit. new tree. new blob.

everything is stored.

everything is linked.

git is just a graph database.

shug messages uncle:

"i get it now"

uncle: "get what"

"commits are linked lists"

uncle: "🎉"

raj messages same time:

"git push not working again"

shug screenshots the git cat-file output.

sends to raj.

raj: "what is this"

shug: "your future"

leaves him on read.

some people aren't ready.

commits are linked (the chain)

shug draws this on paper:

commit 01 ← commit 02 ← commit 03
                          ↑
                        HEAD

each arrow is a parent pointer.

git walks backward through parents.

this creates complete history.

shug finally understands git log.

it's not magic.

git starts at HEAD.

reads current commit.

checks parent. reads that.

checks parent. reads that.

keeps going until no more parents.

that's the log.

simple.

HEAD: your position marker

.git/HEAD

shug opens this file in text editor:

ref: refs/heads/main

one line. that's it.

HEAD points to current branch.

branch points to latest commit.

shug thinks: "so HEAD is like... my cursor in history?"

yes. exactly that.

HEAD = "you are here" marker

make new commit → HEAD moves forward

checkout old commit → HEAD moves backward

tries something:

git checkout e4f5g6h

(checking out old commit directly)

warning message appears:

You are in 'detached HEAD' state...

shug panics.

googles "detached head git"

oh. HEAD just moved off the branch.

now points directly to commit instead of branch name.

not broken. just... floating.

git checkout main

HEAD reattaches.

crisis averted.

the bug scenario (shug's nightmare returns)

remember episode 1?

shug committed bug. broke entire project.

had to rewrite everything from memory.

never again.

scenario:

shug commits bug in commit 03.

realizes 2 commits later at commit 05.

panic mode activated.

but wait.

shug knows git now.

option 1: revert (the safe way)

git revert 03

shug tries it.

git opens editor.

asks for commit message.

shug types: "reverting the bug commit"

saves.

done.

checks git log:

01 ← 02 ← 03 ← 04 ← 05 ← 06 (revert of 03)
                              ↑
                            HEAD

commit 03 still exists in history.

but commit 06 undoes its changes.

bug is gone.

history is preserved.

team can see what happened.

safe. reversible. professional.

option 2: reset (the dangerous way)

shug reads about another option.

git reset --hard

"use with caution" every article says.

shug creates test branch to try it.

git reset --hard 02

poof.

commits 03, 04, 05 disappear from git log.

01 ← 02
      ↑
    HEAD

(03, 04, 05 are gone)

checks working directory.

files reverted to commit 02 state.

all changes after that: deleted.

shug's heart races.

this is powerful.

but dangerous.

what if already pushed to team?

now their history has commits that yours doesn't.

merge conflicts from hell.

quickly undoes test:

git reflog

(shows all HEAD movements, even deleted commits)

finds deleted commit hash.

git reset --hard a1b2c3d

commits are back.

breathes again.

lesson learned:

git revert = safe for shared branches

git reset --hard = only for local mistakes

never reset shared history.

shug writes this on sticky note.

sticks to monitor.

branches revealed (biggest surprise)

shug always thought branch = copy of code.

like:

• main folder with all files

• feature folder with all files copied

heavy. slow. duplicate everything.

wrong.

goes to:

.git/refs/heads/main

opens file.

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0

one line.

just a commit hash.

that's it.

branch = pointer to commit.

nothing more.

no copied files.

no duplicate data.

just a named pointer.

shug stands up.

sits back down.

opens feature branch file:

.git/refs/heads/feature

inside:

x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0

different hash.

different pointer.

that's the only difference between branches.

years of confusion solved in one folder.

creating branch (what really happens)

shug tests this theory.

git checkout -b test-branch

output:

Switched to a new branch 'test-branch'

checks .git/refs/heads/:

new file appeared: test-branch

inside: same commit hash as main.

because created from main.

both point to same commit initially.

makes one commit on test-branch.

checks file again:

hash changed.

now points to new commit.

main still points to old commit.

      main
       ↓
01 ← 02
       ↖
         03 ← test-branch

no duplication.

no copying.

just pointers moving.

brilliant.

shug deletes test-branch:

git branch -d test-branch

checks .git/refs/heads/:

file is gone.

that's all deleting a branch does.

removes the pointer file.

commit 03 still exists in objects folder.

just not pointed to by any branch.

(will be garbage collected eventually)

the snapshot insight

shug reads more about git internals.

article says something weird:

"git doesn't track changes. it tracks snapshots."

reads that again.

what?

every commit = complete picture of project.

not "changed line 12 in file.css"

but "here's entire project at this moment"

shug tests:

changes one line in style.css.

commits.

git show HEAD

output shows:

- color: blue;
+ color: red;

but internally?

git stored entire new version of style.css.

compared both versions.

showed difference.

why do this?

because comparing two snapshots is fast.

tracking individual changes is slow and complex.

snapshots are simple.

git optimizes storage with compression.

but concept is: full snapshots.

shug's mental model updates:

commits aren't deltas.

commits are photographs.

git album of project over time.

config file (repository settings)

.git/config

shug opens it:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
[remote "origin"]
    url = https://github.com/shug/project.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
    remote = origin
    merge = refs/heads/main

readable. editable. just text.

this stores:

• remote repository url (github)

• branch tracking info

• user preferences

• repository settings

can edit manually.

or use commands:

git config user.name "shug"
git config user.email "shug@email.com"

both work.

config file updates either way.

shug changes email:

git config user.email "shug@newmail.com"

checks config file:

[user]
    email = shug@newmail.com

appeared at bottom.

all git config lives here.

no hidden database.

just text file.

everything connects

shug draws final mental map on whiteboard:

1. working directory → where you edit files

2. staging area → temporary selection (git add)

3. repository → permanent history (git commit)

4. objects folder → where data actually lives

5. HEAD → current position marker

6. branches → named pointers to commits

7. commits → linked snapshots with parent pointers

arrows between everything.

the system makes sense now.

not magic.

just clever file organization.

the transformation

shug opens old notes from episode 1.

before:

• copied commands from stackoverflow

• git was black box

• feared every operation

• "what if i break something"

• "why didn't it work"

• panic when errors appeared

after:

• understands what commands do

• can predict git behavior

• reads error messages and knows why

• "oh, HEAD is detached, just checkout main"

• "revert instead of reset for shared branch"

• confidence in daily workflow

the difference isn't commands memorized.

the difference is mental model.

shug knows what's happening inside .git.

commands make sense now.

shug's new powers

now shug can:

• recover deleted code ✅ (git reflog)

• track who changed what ✅ (git log)

• rollback to any point ✅ (git revert or git reset)

• work on features safely ✅ (branches are just pointers)

• collaborate without chaos ✅ (understanding merge/push)

• sleep peacefully ✅ (everything is stored)

the pendrive trauma is healed.

final realization

shug closes laptop.

leans back.

thinks about the journey.

git exists because humans:

• forget things

• make mistakes

• need history

• collaborate badly

• overwrite each other's work

• lose files

git remembers so you don't have to.

.git folder is safety net.

commits are checkpoints.

branches are parallel universes.

HEAD is your position.

shug respects git now. 🧠✨

not just tool.

but philosophy.

version everything.

commit often.

history is freedom.

what shug learned throughout the journey

episode 1: the problem

• collaboration without version control = chaos

• pendrives and email don't scale

• manually tracking versions fails

• humans need automatic memory

• git solves this

episode 2: the basics

• git tracks changes locally

• three-stage workflow: edit → stage → commit

• basic commands for daily work

• github for remote backup

• never lose work again

episode 3: the internals

• everything lives in .git folder

• objects folder stores all data

• commits are linked snapshots

• branches are just pointers

• HEAD tracks position

• git is simple system, not magic

three weeks later

shug helps coworker with git issue.

coworker: "git says detached HEAD, what do i do?"

shug: "checkout your branch name"

coworker: "how did you know?"

shug shrugs: "just know how HEAD works"

explains pointers and commits.

coworker stares.

"you're really good at this"

shug thinks back to episode 1.

remembers crying over lost pendrive.

remembers raj's smug face.

remembers uncle's patience.

look at me now.

the end

raj texts: "can you help with my git"

shug: "did you read the docs?"

raj: "too long"

shug: "then suffer"

some people never learn.

but shug did.

and now?

git is second nature.

.git folder is old friend.

commits flow naturally.

shug conquered git.

(and raj? still emails zip files. 😤)

to be continued?

shug still has questions:

• merge conflicts (when history diverges)

• rebasing (rewriting history cleanly)

• advanced workflows (git flow, trunk-based)

but that's for another day.

for now, fundamentals are solid.

and that's enough.

shug will sleep happily now after sipping his hot cup of chai.

shug opens youtube.

searches: "git tutorial for beginners"

watches 45 minute video.

learns commands:

git init
git add .
git commit -m "initial commit"
git push origin main

shug copies commands.

everything works.

but shug has no idea what just happened.

repeat after me syndrome

for next 3 months, shug's workflow:

1. google "how to push code to github"

2. copy paste commands

3. hope it works

4. it works

5. still no understanding

shug becomes copy paste developer.

the breaking point

one day shug's teammate asks:

"can you merge my branch?"

shug: "what is branch?"

teammate: "you don't know branches?"

shug: "i know git push"

teammate: 😐

time to actually learn.

what git actually is

shug sits down.

reads carefully.

git = version control system

okay but what does that mean in real terms?

git is tool that:

• tracks changes in your code

• stores complete history

• works locally on your computer

• doesn't need internet

git vs github (shug was confused)

shug thought git = github.

wrong.

git → software on your computer (the brain 🧠)
github → website that stores git projects (the cloud ☁️)

analogy:

• git = your brain keeping memories

• github = google photos backup

git works without github.
github is useless without git.

mind blown 🤯

the .git folder revelation

shug types first real command:

git init

nothing visible happens.

but shug checks folder.

hidden folder appears: .git

this is where everything lives.

all history.
all commits.
all branches.
all memory.

delete this folder → git forgets everything

shug stares at .git folder with respect.

how git remembers (the actual flow)

shug draws diagram in notebook:

working directory
      ↓
  git add
      ↓
staging area
      ↓
  git commit
      ↓
.git folder (permanent storage)

step 1: working directory

shug edits index.html:

<h1>hello world</h1>

git notices change.
but does nothing yet.

shug checks:

git status

output:

modified: index.html

git is watching.

step 2: staging area (the waiting room)

git add index.html

change moves to staging area.

staging = "i want to remember this change"

git status now shows:

Changes to be committed:
  modified: index.html

still not permanent.

shug can unstage if needed.

step 3: commit (permanent memory)

git commit -m "added hello world heading"

now git saves it forever.

commit stores:

• what changed (diff)

• who changed it (shug)

• when it changed (timestamp)

• why it changed (commit message)

this snapshot is now permanent.

even if shug deletes file later, git remembers.

the commands shug actually uses

seeing what changed

git status

shows current state.

seeing history

git log

shows all commits.

better version:

git log --oneline

cleaner output.

seeing specific changes

git diff

shows line-by-line changes before staging.

shug's first real workflow

day 1: shug creates project

mkdir my-project
cd my-project
git init

git is now watching this folder.

day 2: shug adds files

touch index.html
git add index.html
git commit -m "added index file"

first commit created ✅

day 3: shug makes changes

edits index.html

git add index.html
git commit -m "updated heading"

second commit created ✅

day 4: shug checks history

git log --oneline

output:

a1b2c3d updated heading
e4f5g6h added index file

shug can see everything that happened

no more mystery.
no more "when did i change this?"

the realization moment

shug accidentally deletes entire file.

panics.

then remembers: git has history.

git checkout HEAD index.html

file comes back.

shug's hands stop shaking.

this is why git exists.

but questions remain

shug understands commands now.

but still confused about:

• where is git storing all this data?

• what is HEAD?

• how do commits connect?

• what are branches actually?

time to look inside.

🎬 continue to episode 3

shug is final year student.

project deadline: 2 days

team size: 4 people

version control knowledge: 0

how it started

shug writes beautiful code.

200 lines of pure genius.

works perfectly.

shug saves on pendrive 💾

gives to teammate raj.

"add your part bro"

6 hours later

raj returns pendrive.

shug plugs in.

opens project.

everything is broken.

shug's 200 lines: gone.

raj's code: partially there.

nobody knows what happened.

the investigation 🔍

shug: "bro what did you do?"

raj: "i just edited some files"

shug: "which files?"

raj: "i don't remember"

shug: "where is my code?"

raj: "i thought you had backup"

shug: 💀

attempts to recover

shug tries everything:

• check pendrive history (doesn't exist)

• ask raj to remember changes (he doesn't)

• restore old version (there is none)

• cry (very effective)

deadline: tomorrow morning.

shug rewrites 200 lines from memory.

takes 8 hours.

graduates with trauma.

the pattern shug notices

this wasn't first time.

there were other incidents.

incident 1: email attachments

• shug emails code to priya

• priya edits, emails back

• shug makes more changes

• both versions exist

• which one is correct? nobody knows

incident 2: whatsapp code sharing

• copy paste code in chat

• loses formatting

• loses context

• loses sanity

incident 3: folders

• project_final

• project_final_v2

• project_final_v2_actually_final

• project_final_v2_actually_final_USE_THIS_ONE

chaos.

the core problem

humans have terrible memory.

files overwrite each other.

history disappears.

questions nobody can answer:

• what changed?

• who changed it?

• when did it change?

• why did it change?

• how to go back?

what shug needed

shug didn't know it yet, but needed:

• automatic memory

• complete history

• ability to rollback

• blame tracking (for raj 😤)

• parallel work without collision

basically:

a time machine for code

senior developer uncle appears

college tech fest.

shug meets senior developer uncle.

tells whole pendrive story.

uncle laughs.

"beta, use git"

shug: "what is git?"

uncle: "version control system. remembers everything."

shug: "everything?"

uncle: "everything. even what raj deleted."

shug's eyes light up ✨

what is version control?

version control = system that remembers every version of your code.

not manually.
not in your brain.
automatically.

like save points in video game.

mess up? go back to last save point.

want to see what changed? compare save points.

the promise

with version control:

• no more lost code

• no more "who changed this?"

• no more "when did this break?"

• no more crying before deadline

collaboration becomes possible.

history becomes permanent.

mistakes become reversible.

shug makes decision

"uncle, teach me git"

uncle: "youtube pe dekh lo"

shug: 😐

what shug learns (preview)

over next few weeks, shug discovers:

• git tracks changes automatically

• git stores complete history

• git lets multiple people work safely

• git lives on your computer

• github stores it online

but first…

shug needs to understand
what git actually does.

🎬 continue to episode 2

Shug like small function, no break. Shug brain work like if-else, not like machine learning black magic.

GPT Mean Generative Pretrained Transformer.

Fancy Word.

Shug Hear. Shug Head Pain.

What This Fancy Name Mean?

Generative Mean GPT Make Thing. You Say "Write Blog". GPT Write Better Blog Than Shug. Shug Cry In Corner. Then Post Anyway.

Pretrained Mean GPT Read Internet. Whole Internet. Even Those Facebook Auntie Recipes. Shug Still Google "How Center Div". Shame.

Transformer Not robot movie. No fight scene. Is math black magic. Paper say "Attention is all you need". Shug laugh. Think love advice. Is not. Shug look at transformer math, full of big tensors. Brain say "why numbers in 12D?" Shug close laptop, go drink garam chai.

OpenAI name it ChatGPT. Simple. Genius. Like naming dosa "Dosa". World clap. Competitors cry in JavaScript.

So GPT = Internet Hoarder + No Sleep + Too Smart. Basically That Friend Who Know Everything And Never Let You Copy Code. But GPT Let You Copy. Good Bot.

Shug no jealous. Maybe little jealous.

In the end, big brain GPT predict next token. Shug happy. Shug safe.

Shug brain tired. Time for garam chai. Bye.

Our mom would ask us to find a random letter and we would open the book and search for the letter by referencing the image (For example M for Mango then you would search for a mango image in the book).

But as you grew up, you became an expert at finding the alphabet in the book. If your mom asked you to find M, then you would be smart enough to know that M will be on some centre page. You would start searching it directly from some random middle page 😎

Now let's just analyse the example that I gave.

If you think about it, there are two approaches you can take to find the alphabet.

1. Searching every page from the beginning until you find the alphabet.
2. Opening a random page and searching the alphabet.

The second method seems an intelligent move to find the alphabet the fastest way right😉

So now let me share something with you🤫

The first approach which we discussed is called Linear Search. You are linearly searching the alphabet without skipping a single page until you find the desired alphabet.

For finding the alphabet using Linear search we will start searching from page 1 until we get the alphabet we are looking for. Let's say you are searching for the letter D. Using Linear Search you will start from the letter A and keep flipping the page unless it's D.

This seems to be taking a long time, right? And did you think of searching for the letter Z? We would have to make 25 searches and after that, we would find Z😵‍💫

Imagine finding a word in the dictionary by using the Linear Search method😶‍🌫️

What is the fast alternative?🤔

Remember the second method, the smart move we made while searching the alphabet? Based on the alphabet we had to search we were opening pages randomly and searching them!

Let's discuss a little about this method.

So let's take an example of finding the letter M in the book. Suppose the page number is from 1 to 26 where on page 1 there is the letter A and so on. Now smartly you will think that the letter M lies somewhere in between i.e. on page 13. Tada, on page 13 there will be the letter M (Since M is the 13th alphabet). So for the linear search, you would take 13 steps to find M, but by using the smart way you found M in the first step!

Isn't that amazing?🤩

But remember this method will work only if the alphabets are in order. Otherwise, this method is useless and we will have to use the Linear search.

The smart way we have learned so far can help us locate any alphabet in a few steps. The only condition required is that the alphabet should be sorted. Binary Search is the smart way of doing this.

Let us now understand how binary search can help us find our desired output in a few steps. Let's take an example of finding the letter F.

Steps:

1. Find the middle element First, we will find the middle alphabet. Here the middle alphabet is the letter M.
2. Check if the target is greater or smaller than the middle element The letter F lies before the letter M. So we can say that the letter F is smaller than the middle alphabet.
3. If the target is smaller than the middle element then search on the left side So we will now check for the target from the start to the middle alphabet i.e. We will search for the letter F in between A and M.

So if you look closely we are reducing the range of searching and we are finding the target. The half of 13 is 6 (considering the integer value) and on page 6 there will be the letter F (Since F is the 6th alphabet). This is how we found the letter F in 2 steps using Binary Search.

To summarise, We need to follow the following steps for Binary search:

1. Find the middle element.
2. Check if the target is greater or smaller than the middle element.
3. If the target is greater than the middle element, search on the right-hand side.
4. Else, if the target is smaller than the middle element, search on the left-hand side.
5. Repeat steps 2, 3 and 4 till the middle element is equal to the target.

Let's take another example.

The first thing you should check before applying Binary Search is to check whether the given range is sorted. Once we verified, you can go ahead and apply binary search.

1. Find the middle element.

   The middle element in the above array is 11. (4th element in the array is 11)

   middle = (start + end) / 2 
   middle => (0 + 9) / 2 
   middle => 4
   

2. Check if the target is greater or smaller than the middle element.

   If the target element is greater than the middle element, check on the right side.

   if ( target > middle ) => check on the right
   

   Whereas, If the target element is smaller than the middle element, check on the left side.

   if ( target < middle ) => check on the left
   

   In our case, 36 > 11, thus we have to check on the right side.

Repeating steps 1 and 2 again.

middle = (start + end) / 2 
middle => (5 + 9) /2 
middle => 14 / 2 
middle => 7

The 7th element in the array is 20. In this case 36 > 20, thus we again have to check on the right side.

Repeating steps 1 and 2 again.

middle = (start + end) / 2 
middle => (7 + 9) /2 
middle => 16 / 2 
middle => 8

The 8th element in the array is 36. Hurray! we have finally found out 36.

If you see we have found 36 in just 4 steps. If we used linear search, we would require 8 steps to find 36.

Let's now understand the Time complexity of Binary search.

Here the space in which we are searching is getting divided into two parts.

In the first step, when the array is not split, the size of the array is,

N / 2^0

In the second step, it becomes

N / 2^1

In the third step, it becomes

N / 2^2

Thus at the k^th step,

N / 2^k = 1

It is equal to 1 because the size of the array is reduced to 1 element only i.e. the target element.

Thus if we solve this further,

N = 2^k    // Shifting 2^k on the Right side
log ( N ) = log ( 2^k )    // Taking log on both sides
log ( N ) = k * log( 2 )
log ( N ) / log ( 2 ) = k
k = log2 ( N )

Here k is the total number of comparisons done while finding the target element and N is the size of the array. Thus the time complexity of Binary search is O(log (N)).

Now that you have a fundamental understanding of Binary Search, you can easily understand its implementation in any programming language you like!

Did you find this useful?🤔 Feel free to like and save it to your timeline for reference later!😊

Thanks for reading ✨