Forem: Satpalsinh Rana

Domain Name System (DNS): What It Is and How It Functions

Satpalsinh Rana — Sat, 24 Jan 2026 10:33:14 +0000

The Internet Addressing System

In the world of the internet, every device (node) connected to the network needs a unique identifier to communicate. This identifier is known as an IP Address. You can think of it like the GPS Coordinates of your House.

1. IPv4 (Internet Protocol version 4)

This is the legacy format we are most familiar with. It looks like 192.168.0.1.

Format: It consists of four octets separated by dots. Each octet is a decimal value between 0 and 255.
Capacity: IPv4 uses 32 bits. Total Addresses = 2³² = 4,294,967,296 (~4.3 billion)

As the internet has evolved, our devices have become smarter. We now have internet connected Air Conditioners, Washing Machines, Cars, and countless IoT devices. With billions of humans and tens of billions of devices, the 4.3 billion IPv4 addresses have essentially been exhausted.

2. IPv6 (Internet Protocol version 6)

To solve the exhaustion problem, IPv6 was introduced. It looks like 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

Format: It uses hexadecimal format.
Capacity: IPv6 uses 128 bits. Total\ Addresses = 2¹²⁸ = 340,282,366,920,938,463,463,374,607,431,768,211,456.

That is 340 undecillion addresses. We will not run out of IP anytime soon.

The Human Brain

Let’s understand how the human brain works. Our brains are wired to love strings, words, names, and stories. Not long, random numbers.

Imagine a friend comes to you and says:

"I have two houses. The first is located at GPS Coordinates 28.6139° N, 77.2090° E, and the second is at 19.0760° N, 72.8777° E."

You simply won’t remember that. However, it is instantly clear and memorable if they say:

"11, Elite Bunglows, New Delhi, India" or "15, Chai Bunglows, Mumbai, India."

The internet works the same way. When you want to visit a website, you shouldn’t have to memorize a server’s IP address. You need a memorable name. This is where Domains come in.

Domain

A domain is a unique, human-readable name that identifies a resource on the Internet and maps to one or more IP addresses using the Domain Name System.

Have you heard of ICANN?

ICANN (Internet Corporation for Assigned Names and Numbers) is the global organization responsible for coordinating the allocation of domain names and IP address spaces to ensure uniqueness across the Internet.

You can think of ICANN as the global registry and policy authority that oversees:

Domain name uniqueness
Top-level domains like .com, .org, .in
IP address distribution through regional registries

Because of ICANN’s coordination, when you type google.com, it resolves to Google’s servers and not to any other organization. No two entities can own the same domain name in the global DNS system.

So now, you understand what a domain is.

Question Time: When you type google.com into your browser, how exactly is that IP address found?

You might be wondering:

Does my Chrome browser memorize every IP on the internet? (Sorry Brave fans.)
Does my laptop know where Google is hosted?
Or is there some mysterious third-party service doing the work?

The answer is a big No.

No single device knows everything. The internet is too big (remember, millions of websites). Instead, it works like a Detective Investigation. And the system that does the investigation is known as the Domain Name System.

DNS

DNS translates Domain names to IP addresses.

DNS services include:

Host to IP address.

E.g. google.com to 142.251.220.14
Host aliasing

Allows multiple domain names to map to the same canonical domain using CNAME records.
Email routing

Allow a domain to specify which mail servers are responsible for receiving the email.
IP address to Host

E.g. 142.251.220.14 to google.com
Load Balancing

DNS Resolution: The Hierarchy of "Whom to Meet Next?"

When you type google.com, your browser doesn't get the IP address in one magical shot. It is a hierarchical, recursive process.

Think of it like looking for a person living in a massive office building. You don't know where they live, so you ask for directions. Each person you ask doesn't give you the final answer, they just answer the question: "Whom should I meet next?"

Let's trace the journey of google.com:

Step 1: Browser Cache

Before doing anything, your browser (Chrome, Firefox, Safari) checks its own temporary memory.

The Question: "Have I visited google.com in the last few minutes?"
If Yes: It uses the saved IP immediately. No network request is made.
If No: It proceeds to Step 2.

Step 2: OS Cache

The browser asks your Operating System (Windows, macOS, Linux). The OS maintains its own cache and also checks a special text file called the "hosts file".

The Question: "Hey Windows, do you have a record for google.com?"
If Yes: The OS gives the IP to the browser.
If No: The OS realizes it doesn't know the answer locally. It needs outside help.

Step 3: The DNS Resolver (The Assistant)

Browser is the Boss. The Boss is busy rendering pages and chats of ChatGPT, it doesn't have time to run around the internet asking for directions. So, when the cache comes up empty, the Browser delegates the task to its assistant.

This is the moment your request actually leaves your computer. The query travels to the Resolver, which is usually provided by your ISP (Internet Service Provider) or a public DNS service like Google (8.8.8.8) or Cloudflare (1.1.1.1).

The Question: "I need the IP for google.com. Go find it for me."
The Resolver's Job: It is now the Resolver's responsibility to hunt down the answer. It starts the "Whom to meet next?" journey across the internet.
It’s check inside it’s cache. Because the resolver caches this result for a time period called TTL (Time To Live) so that future requests can be answered faster without repeating the entire process.
If No: It goes to Root DNS Server.

Step 4: The Root DNS Server (.)

The Resolver asks the Root Server.

Answer: "I don't know the IP, but google.com ends in “.com”. Go ask the “.com” TLD Server."

Step 5: The TLD DNS Server (.com)

The Resolver asks the “.com” TLD Server.

Answer: "I don't know the IP, but I know google.com is managed by Google's Name Servers. Go ask the Authoritative Server."

Step 6: The Authoritative Name Server

The Resolver asks Google's Authoritative Server.

Answer: "Yes, I am the authority. The IP address is 142.251.220.14."

The Finish Line: The Resolver brings this IP back to your Browser and finally, the website loads.

Tea Break ☕ :)

Question Time: How does it know when to stop?

It checks the Answer Type:

"Go Ask Someone Else" (NS Record): The Resolver knows to keep going to the next server.
"Here is the IP" (A Record or AAAA record for IPv6): The Resolver knows the search is finished.

We’ve seen how the detective works in theory. Now, let’s hand you the badge and let you do the investigation yourself. Meet our friend DIG, a command-line utility.

DIG

DIG stands for Domain Information Groper. As the name suggests, we can use this utility to perform DNS queries.

Let’s try using dig for google.com in the terminal, or try it online:(https://toolbox.googleapps.com/apps/dig).

dig google.com

You will get a lot of output, but don't panic. You only need to look at the "ANSWER SECTION":

Domain         TTL       Internet       Type        IP Address
----------------------------------------------------------------
google.com.    120         IN            A        172.217.25.78

Now you understand how to query DNS using DIG. But what is TTL?

TTL

TTL stands for Time To Live. It is the amount of time a DNS record can be cached before it must be re-queried. This is why, when we update a DNS record, it takes time for the change to be seen everywhere.

Imagine a resolver asks for Google’s IP and gets the answer. The resolver stores it in its cache and sets a timer (TTL) for 1 hour.

Now, imagine 5 minutes later, Google’s admin changes the IP address on the authoritative DNS server.

But, The resolver doesn't know. If your browser asks the resolver again, the resolver will not go back to the server. The resolver will just look at their cache, see the valid timer, and give you the old (now wrong) IP address.

This is why we say the update "takes time to propagate." Propagation is not the time it takes for data to travel across the internet, it is the time we spend waiting for everyone's timers to run out.

DIG commands

Quick Check: You just want the IP address.

dig google.com +short

Full Investigation:

dig google.com +trace

Return the log containing:

Block 1 (The Root): You asked the Root Server. It said: "I don't know, go ask the .com servers."
Block 2 (The TLD): You asked the .com Server. It said: "I don't know, go ask Google's Name servers."
Block 3 (The Authority): You asked Google's Name Server. It said: "Here is the IP: 172.217.26.206."

Get Authoritative Name Server:

dig google.com NS

Check with Google or Cloudflare Resolver:

dig @8.8.8.8 google.com #Google DNS resovler
#OR
dig @1.1.1.1 google.com #CloudFlare DNS resolver

Reverse Lookup

dig -x 142.251.220.14

This uses PTR records under the in-addr.arpa domain.

Summary

The Domain Name System (DNS) is a critical component of the internet that translates human-readable domain names into machine-readable IP addresses. It allows users to access websites without needing to remember complex numerical addresses, ensuring efficient and seamless communication across the digital landscape. Understanding DNS processes and tools can help optimize internet interactions.

"The best technology is the kind that works so well you don't even notice it."

— Anonymous

What's Inside the .git Folder?

Satpalsinh Rana — Fri, 09 Jan 2026 20:36:04 +0000

In this article, we are going to open the hood and look at the engine. We are going to explore the .git folder.

By the end of this article, you’ll understand how Git stores files, tracks history internally, and how commits are built under the hood.

Prerequisites

Before we dive into the hexadecimal rabbit hole, let’s make sure we are on the same page. You don’t need to be a Git wizard to follow along, but you should be comfortable with:

Basic Git Commands: You have used git add, git commit, and git push before.
The Command Line: You know how to open a terminal and navigate folders (cd, ls).
Curiosity: You are willing to look at things that might seem abstract at first!

New to Git?

If you want to refresh the basics first, check out:

Learn Git Easily: A Beginner's Guide to Version Control

What is the `.git` Folder ?

If you open any Git repository on your computer and enable "show hidden files," you will see a folder named .git .

This isn't just a config folder, it is a database. It is the brain, heart, and soul of your repository. If you delete your project files but keep the .git folder, you can restore everything. If you delete the .git folder, your project becomes just a regular folder of text files, and all your history is lost.

Git is essentially a content-addressable filesystem. That’s a fancy way of saying it’s a key-value store.

Blob: When you create a file like main.ts , Git looks at the contents of that file. It compresses the content and stores it as a Blob.
Tree: A blob has content, but it doesn't have a name. That's where the Tree comes in. It maps names (like main.ts) to Blob IDs. It can also contain other Trees (subdirectories). This is how Git reconstructs your folder structure.
Commit: The Commit object is the wrapper that ties it all together. A pointer to a specific Tree, metadata, and a pointer to the parent commit.

In Simple terms:

Blob: The data (File content).
Tree: The structure (Folder organization).
Commit: The snapshot (Who, when, and why).

SHA-1 Hashes

You’ve likely seen those long strings of random characters like a1b2c3d... . This are SHA-1 Hashes.

Every time you create an object, Git runs a mathematical formula on the content to generate this 40-character ID.

Here, SHA stands for Secure Hash Algorithm.

Newer versions of Git now support SHA-256 as an option, but it is not the default yet because the entire ecosystem (GitHub, GitLab, tools) is still built around SHA-1 compatibility.

To check which hashing algorithm your specific Git repository is using, you can run this command in your terminal inside the repo:

git rev-parse --show-object-format
# rev-parse - Git plumbing command that resolves and parses Git references (hashes, branches, tags)
# --show-object-format - Displays the object hash format used by this repository (sha1 or sha256)

What happens when you commit?

Let’s trace the journey of a file from your editor to the repository.

Step 1: git add .

When you run git add, you aren't just "marking" files. You are actively writing to the database.

Git takes the content of your modified files.
It creates Blob objects for them immediately and stores them in .git/objects.
It updates the Index (or Staging Area). The Index is just a list that says, "For the next commit, this filename points to this specific Blob hash."

Step 2: git commit -m "Message"

When you run git commit, Git creates a permanent snapshot.

Tree Creation: Git looks at your Index (Staging Area) and creates Tree objects that represent your current folder structure.
Commit Creation: Git creates a Commit object. This object points to the main Tree you just created and links back to the previous commit (the parent).
Head Update: Finally, Git moves the HEAD pointer (your current branch label) to point to this new commit ID.

So, this is where the integrity magic happens.

If you have a file with the text "Hello World", the hash will always be the same.
If you change "Hello World" to "Hello Worlds", the hash changes completely.

Git hashes not only the content, but also the object type and size. This guarantees uniqueness and integrity. Git objects don't just exist in isolation, they point to each other using these hashes. This dependency creates a chain reaction. This happens because every commit also includes the hash of its parent commit.

Deep Dive: Folder Structure

HEAD (The "You Are Here" Pointer)

The HEAD file is a simple text file that tells Git where you are currently working. It contains a reference to the active branch.

If you open it, you will typically see:

ref: refs/heads/main

This tells Git: "We are currently on the main branch." When you run git checkout dark-mode, Git simply updates this file to point to refs/heads/dark-mode. It is essentially a dynamic pointer.

objects/ (The Database)

This is the most important folder. It acts as the local database where Git stores all your data—content (blobs), folder structures (trees), and history (commits).

Every object is stored here, named by its unique SHA-1 hash.

How to inspect an object: Since these files are compressed binaries, you cannot open them in a text editor. Instead, use the git cat-file command to read them.

git cat-file -p <object-id>

-p: Pretty-print the content (make it human-readable).

Example Output of a Commit Object:

tree 8d3a1...
parent 1f4e2...
author Satpal Rana <satpal@example.com> 1703865000 +0000

Created the homepage hero section

refs/ (The Bookmarks)

If objects/ is the library of books, refs/ is the catalog of bookmarks. This folder stores your Branches and Tags.

Heads: Found in refs/heads/. If you have a branch named feature-login, there is a file named feature-login in this folder.
The content: The file contains nothing but a 40-character Commit Hash.

This is why creating branches in Git is so fast. Git doesn't copy your files, it just creates a tiny text file containing the hash of the current commit.

index (The Staging Area)

This is a binary file that acts as the "Staging Area." When you run git add, Git updates this index file. It builds a list of file information (timestamps, filenames, and blob hashes) that are ready to be packaged into the next commit.

config (Project Settings)

This text file contains configuration specific to this repository, such as:

The URL of the remote repository (origin).
Local user overrides.
Branch tracking information.

Hand’s On Git

Create a new repository:

git init demo
cd demo

Create a file and commit it:

echo "Hello Git" > hello.txt
git add .
git commit -m "First commit"

Explore the objects:

ls .git/objects
git cat-file -p <object-id>

Observe how Git stores and retrieves data internally.

In this article, we explored how Git stores data internally using blobs, trees, commits, and hashes. Understanding this makes Git feel less magical and more predictable.

“Hidden folders sometimes hold the biggest secrets.”

— Anonymous Developer

Learn Git Easily: A Beginner's Guide to Version Control

Satpalsinh Rana — Thu, 01 Jan 2026 17:43:02 +0000

If you have ever struggled with sharing your code via pen drives or sending endless zip files through email, you are in the right place. It’s time to introduce you to Git.

Git

In technical terms, Git is a Distributed Version Control System (DVCS).

In simple terms, Git is a time machine for our projects. It tracks every modification you make to our code. If you break something, you can simply "rewind" to a previous state where everything worked.

Why do we use it?

Collaborations: Multiple people can work on the same file at the same time without overwriting each other’s work.
Distributed Architecture: Every developer gets their own local version of the repository with the full history and commits. It supports offline work and has no single point of failure.
Branching and Merging: Developers create a separate branch to work on a feature and can merge it into the main branch.

Terminology Dictionary

Developers love using fancy words for simple things. Here is your translation guide to help you go through the article.

Term	What it means
Repository (Repo)	The folder containing all your project files and the entire revision history.
Commit	A snapshot of your code at a specific point in time. It has a unique ID (hash).
Staging Area	The list of files you are planning to commit next.
Local	The version of the repository stored on your personal computer.
Remote	The version of the repository stored on the internet (like GitHub/GitLab).
Clone	Downloading a remote repository to your computer.
Push	Uploading your local commits to the remote server.
Pull	Downloading changes from the remote server to your local machine.
Merge	Taking code from one branch and combining it into another.
Branch	A parallel version of your code. Changes here do not affect the main project until you merge them.
HEAD	A pointer to the specific commit you are currently looking at or working on.
Origin	The default nickname Git gives to the remote URL (where you cloned from).
Pull Request (PR)	A request to merge your branch into the main branch. (Used on GitHub/GitLab).

The Core Architecture

Before moving to the commands, we must understand the three stages.

Working Directory (The Workbench): This is the actual folder where we type our code.
Staging Area (The Box): Pick specific files from the workbench and put in the box.
Local Repository (The Shipping Truck): You seal the box and label it. This is a Commit. It is part of the code history now.

How a Repository looks

src/: The folder containing your actual source code, keeping the project organized.
.gitignore: A text file listing everything Git should intentionally ignore (like secrets).
README.md: The instruction manual that explains what your project is and how to run it.
LICENSE: The legal document stating how others are allowed to use or copy your code.
.git/: The hidden database where Git stores your entire project history and save points.

The Developer Workflow

Initialize

Tell Git to watch your folder

git init

Check Status

Want to check your repo’s status

git status

Stage

Create a file named index.html. Now run git status again. You will see the file in red (Untracked). Let's move it to the staging area using the command below.

git add index.html

To add all changed files at once, use git add .

Run git status again. The file is now green. It is staged and ready to be saved.

Commit

Now we permanently save this snapshot to the history. You must include a message describing what you did.

git commit -m "Created the homepage file"

-m: Stands for "message".

Lazy Shortcut

Tired of typing git add and then git commit every single time? We can combine them into one command.

git commit -am "Updated the style"

It will NOT stage new (untracked) files. Only modified/deleted tracked files.

History

To see a list of all your saves

git log

Difference

Before you stage or commit, you should always check what you actually changed.

git diff

Branching

Create Branch

By default, we are on the main (or master) branch. Let's create a new timeline:

git branch dark-mode-feature

Switching Branches

Now we can switch to our new branch.

git checkout dark-mode-feature

Newer Git versions also support git switch dark-mode-feature

Merging

You wrote your code in dark-mode-feature, committed it, and tested it. It works! Now you want to merge it back into the main branch.

Switch back to main: git checkout main
Merge the feature: git merge dark-mode-feature

Going Remote

So far, everything has happened on your computer (Local). To share code, we need a Remote repository.

Clone

Download existing Repo to local

git clone <url>

Push

Upload local commits to remote Repo

git push origin main

Pull

Download new changes from cloud to local computer

git pull

Corporate Kit

Stash

You are working on a new feature (messy code, half-broken). Suddenly, your boss says, "Critical bug! Fix it now!" You can't switch branches because your work isn't done, but you can't commit it yet either. We want to put our changes in a temporary storage drawer.

git stash

Pop Stash

To get your stash back

git stash pop

Reset

Sometimes you commit too early and want to go back. git reset lets you move back to provided commit, but it comes in two flavors.

Soft Reset: Undoes the commit but keeps your code changes in the staging area.

# Go one commit back (keep changes staged)
git reset --soft HEAD~1

# Go one commit back (keep changes unstaged) - mixed reset
git reset HEAD~1

# Go to a specific commit
git reset <commitHash>

Hard Reset: Undoes the commit and deletes all changes. It reverts everything to exactly how it was before you started working.

# Go one commit back (delete commit + delete changes)
git reset --hard HEAD~1

# Go to a specific commit (delete all changes)
git reset --hard <commitHash>

Warning: This deletes your work permanently. Burning the bridge behind you. There is no going back.

Revert

You already pushed bad code to the shared main branch. You cannot use reset (because deleting history that others have downloaded will cause conflicts for other developers). Create a new commit that does the exact opposite of the bad commit.

git revert <commit-id>

Git Cherry-Pick

Your teammate is working on a huge Experimental branch with 50 commits. They fixed a tiny bug in one of those commits. You want that bug fix, but you don't want the rest of their experimental code. Pick just that one commit and apply it to your branch.

git cherry-pick <commit-id>

Rebase

You are working on a feature branch. Meanwhile, the main team has added 10 new updates. Your branch is now out of date. Instead of a messy merge, you rebase. This picks up your work and places it on top of the latest code, keeping the history in a straight line.

git rebase main

Tip

In case of fire: git commit, git push, leave building.

— Anonymous Developer

Git The Game Changer

Satpalsinh Rana — Sun, 28 Dec 2025 11:09:34 +0000

The Tale of the Overwritten Code

Once upon a time, there were two frontend developers, Jon and Arya, working on the launch website for "Winterfell Watch."

Jon was responsible for styling the new "Hero Section" (the big banner at the top). Arya was responsible for the "Contact Form" at the bottom.

It was Friday night, and the Martin wanted the site live by morning.

The Handoff Jon finished the Hero Section. It looked majestic with a new bold font. He felt good. He compressed the folder and named it: 📁 Winterfell_final.zip

He emailed it to Arya so she could add her work.

The Fix Arya downloaded Jon's zip file. She started working on her part. She noticed the Contact Form submit button was broken (🐛). She wrote the JavaScript to fix it. While she was there, she also adjusted the padding on the footer.

She saved her work, zipped the whole project, and named it: 📁 Winterfell_Arya_Fixed.zip

She emailed it back to Jon and went to grab a coffee.

The Disaster Strikes Jon received the email, but before he opened it, he noticed a typo in his Hero Section headline.

“I’ll just fix this quickly on my local copy before I merge Arya’s stuff,” he thought.

He opened the folder on his desktop (his version, before Arya’s fix). He fixed the typo. Then, thinking he was being efficient, he simply dragged Arya's folder into his, clicked "Replace All" to get her files, and then... he hesitated.

He realized his styles.css was newer than hers because he just fixed the typo. So he chose "Keep My File" for the stylesheet.

He zipped the result as: 📁 Winterfell_Launch.zip

The Result They deployed the site.

The Good: Jon’s typo was fixed.

The Bad: Because Jon kept his version of the stylesheet, Arya’s footer padding changes were deleted.

The Ugly: Because of the messy copy-paste, the JavaScript file linking broke. The Contact Form didn't work at all.

The Backup Nightmare Jon looked at his desktop. It was a graveyard of zip files.

He had no idea which folder contained the working Contact Form code. He had overwritten Arya's bug fix with his typo fix.

The Realization Arya stared at the broken form and sighed. "Jon, we are professional developers. We shouldn't be emailing zip files like it's 300 AC. We need a way to merge my footer and your header without erasing each other."

The Single Source of Truth

After the "Launch Ready" disaster, Jon and Arya realized the root of their problem wasn't bad luck it was bad architecture.

They had been operating with Two Sources of Truth: Jon’s laptop (which believed the Hero Section was most important) and Arya’s laptop (which believed the Contact Form fix was most important).

Here comes our savior 🧑‍💻 “The mindful engineers of the world“ who introduced the version control system.

Local Version Control

Concept: Engineers created a local database on their computer that stored changes to files.
Problem: If Jon wanted to share code with Arya, he still had to email it. It solved the "Undo" problem, but not the "Collaboration" problem.

Centralized Version Control

Concept: It contains a single server which stores the changes to files.
Problem: Single point of failure. If Night king attacks the server it will go down. If the central server goes down, nobody can commit or collaborate because the server is the single point of truth.

Distributed Version Control

Concepts: The code lived everywhere, safely duplicated across the Server and every Local machine.
Example: Git, Mercurial, Fossil, and Bazaar

GIT - Time Machine for our code

Back to our story.

Initialize Repository

git init

Jon casts a spell on his project folder, transforming it from a normal directory into a repository watched by the Time Machine (GIT).

Selection

git add index.html

Jon tells Git to include “index.html” in his next save point.

Then he created a large number of files and wanted all untracked files to be included in the next save point.

git add .

Save Point

git commit -m "First Commit by Jon"

Jon created a checkpoint.

History

git log

Jon can now see the history of the code changes.

Sharing

git push

Jon pushes all his save points to the “The Remote Kingdoms” in night. So, Arya will get an update.

Copy

git clone <url>

Sansa joins the team. She needs a perfect clone of the repository on her device.

Update

git pull

As Jon pushed all his changes at night in the “The Remote Kingdoms”. In the morning, Arya wants the latest code, so she types pull and get all the save points from the “The Remote Kingdoms”.

Parallel Verse

git branch dark-mode

Sansa wants to work on dark mode. So, she create a branch and checkout to the dark-mode branch and started her work on it.

git checkout dark-mode

Combination

Sansa completed her development and want to merge the Dark Mode back to the main branch.

So she teleport back to main branch and spell below merge command.

git checkout main
git merge dark-mode

Correction

Sansa realizes that there is commit which contains a bug 🐛 in the “Dark Mode” development which was merged.

But she can’t time travel back (reset) because Arya already downloaded (pulled) the code in her local. So, she decided to revert particular commit.

  git revert <commit-id>

Time Travel (Handle it carefully)

Jon want to travel back to some a save point (e.g. a1b2c3). He uses the below spell to forcefully rewind time back to that exact moment (a1b2c3). Everything after that moment is erased. Using reset --hard after sharing code (push) is dangerous because it rewrites history and can break everyone’s repo.

git reset --hard <commit-id>

The Remote Kingdoms

Once Jon, Sansa and Arya learned to push their code to the cloud, Robb revealed a secret of remote kingdoms and their kings:

GitHub (The Kingdom of Open Source)

The largest kingdom in the realm. Developers across the Seven Kingdoms gather here, creating alliances through Pull Requests and winning glory with Stars.

GitLab (The Fortress of DevOps)

A more disciplined kingdom. Known for pipelines, CI/CD dragons, and strict military formations.

Bitbucket (The House of Private Repositories)

A quieter, more introverted kingdom. Mostly favored by the Houses of Atlassian and Jira Knights.

Deep Dive

Once Jon asks Robb, “Where does this Time Machine GIT actually live? Is it magic?"

Robb opened a project folder and enabled “Show hidden files”. There, sitting quietly at the top, was a folder named 📁 .git .

Let’s open this folder and see how the engine works.

HEAD (You are here)

Open file in notepad, it contains something like: ref: refs/heads/master. It tells Git where you currently are. When Jon teleports using git checkout dark-mode, Git updates this file to point to the dark-mode branch and now it would contains ref: refs/heads/dark-mode.

objects/ (The Database)

It’s the storage space for Git. It stores blobs, trees, and commits, each named after their SHA-1 hash.

So, when Sansa takes a snapshot git commit then git compress, calculates their unique ID, and throws them into this bucket.

If you want to read file use below command:

git cat-file -p <object-id>
# cat-file: "Show me the file."
# -p: "Pretty-print it" (Make it human-readable).

Content:

tree 8d3a1...
parent 1f4e2...
author Jon Snow <jon.dev@winterfell.com> 1703865000 +0000

Created the homepage hero section

refs/ (Bookmarks)

This folder stores your Branches and Tags.

When Sansa created a branch named dark-mode, Git simply creates a new file in this folder named dark-mode and writes the current Commit ID inside it.

config (Project Settings)

This is where your local settings for your project live.

index (Staging Area)

When Jon types git add, Git updates this index file to build the list of what will be in the next save point.

Moral of the Story

And so, with Git guarding their code like a sworn member of the Night’s Watch, Jon, Arya, and Sansa finally worked together without accidentally destroying each other’s changes.

They no longer feared overwritten files, broken features, or mysterious zip-file dragons lurking on their desktops.

Every change had a history.

Every branch had a purpose.

Every mistake had a safe way back.

Great teams don’t just write good code, they protect it with good practices.

And Git is the shield that keeps chaos beyond the Wall.

Forem: Satpalsinh Rana

Domain Name System (DNS): What It Is and How It Functions

The Internet Addressing System

The Human Brain

Domain

DNS

DNS Resolution: The Hierarchy of "Whom to Meet Next?"

Step 1: Browser Cache

Step 2: OS Cache

Step 3: The DNS Resolver (The Assistant)

Step 4: The Root DNS Server (.)

Step 5: The TLD DNS Server (.com)

Step 6: The Authoritative Name Server

DIG

TTL

DIG commands

Summary

What's Inside the .git Folder?

Prerequisites

What is the .git Folder ?

SHA-1 Hashes

What happens when you commit?

Deep Dive: Folder Structure

HEAD (The "You Are Here" Pointer)

objects/ (The Database)

refs/ (The Bookmarks)

index (The Staging Area)

config (Project Settings)

Hand’s On Git

Learn Git Easily: A Beginner's Guide to Version Control

Git

Why do we use it?

Terminology Dictionary

The Core Architecture

How a Repository looks

The Developer Workflow

Initialize

Check Status

Stage

Commit

Lazy Shortcut

History

Difference

Branching

Create Branch

Switching Branches

Merging

Going Remote

Clone

Push

Pull

Corporate Kit

Stash

Pop Stash

Reset

Revert

Git Cherry-Pick

Rebase

Tip

Git The Game Changer

The Tale of the Overwritten Code

The Single Source of Truth

Local Version Control

Centralized Version Control

Distributed Version Control

GIT - Time Machine for our code

Back to our story.

Selection

Save Point

Sharing

Copy

Update

Parallel Verse

Combination

Correction

Time Travel (Handle it carefully)

The Remote Kingdoms

GitHub (The Kingdom of Open Source)

GitLab (The Fortress of DevOps)

Bitbucket (The House of Private Repositories)

What is the `.git` Folder ?