So I just learned about CSS selectors, and honestly? It finally made CSS click for me. If you've ever wondered how CSS "knows" which element to style, this is the answer. Let me break it down the way I understood it.

Why Do We Even Need Selectors?

Imagine you're in a crowded room and you need to call someone. You could shout "Hey, person!" — but everyone would turn around. Not helpful.

Instead, you'd be more specific:

• "Hey, everyone wearing red shirts!" (a group)

• "Hey, Rahul!" (a specific name)

• "Hey, employee #4521!" (a unique ID)

CSS selectors work the exact same way. They're how you point at HTML elements and say "YOU. I want to style YOU."

Without selectors, CSS would have no idea what to target. They're literally the foundation of everything in CSS.

The Selectors (From Broad to Specific)

1. Element Selector

The most basic one. You just write the tag name.

p {
  color: gray;
}

This styles ALL <p> tags on your page. Every single one. No exceptions.

Before: Plain black paragraphs everywhere.
After: Every paragraph turns gray.

Simple, but not very precise.

2. Class Selector

Now we're getting somewhere. Classes let you group elements that should share a style.

<p class="highlight">Important text</p>
<p>Normal text</p>

.highlight {
  background-color: yellow;
}

Notice the dot (.) before the class name? That's how CSS knows it's a class.

Before: Both paragraphs look the same.
After: Only the one with class="highlight" gets a yellow background.

You can reuse classes on as many elements as you want. That's the whole point.

3. ID Selector

IDs are for unique elements. Think of it like a roll number — only one student has it.

<div id="main-header">Welcome!</div>

#main-header {
  font-size: 32px;
  font-weight: bold;
}

The hash (#) symbol indicates an ID. Use IDs when something appears only once on a page (like a navbar or footer).

4. Group Selectors

What if you want to apply the same style to multiple different elements? Instead of repeating yourself, group them with commas.

h1, h2, h3 {
  font-family: 'Arial', sans-serif;
}

This applies the same font to all three heading types. Clean and efficient.

5. Descendant Selectors

This one's cool. You can target elements inside other elements.

<div class="card">
  <p>I'm inside a card</p>
</div>
<p>I'm outside</p>

.card p {
  color: blue;
}

Only the <p> inside .card turns blue. The other paragraph stays untouched.

The space between .card and p means "find p elements that are descendants of .card".

Quick Note on Priority

When multiple selectors target the same element, CSS has to decide who wins. Here's the basic hierarchy:

Element (p, div)  →  Weakest
Class (.highlight)  →  Stronger
ID (#main-header)  →  Strongest

So if you have:

p { color: black; }
.highlight { color: blue; }
#special { color: red; }

And your HTML is:

<p id="special" class="highlight">What color am I?</p>

The text will be red because ID beats class, and class beats element.

There's more to specificity than this, but for now, just remember: ID > Class > Element.

Wrapping Up

Here's my mental model:

Selectors are genuinely the backbone of CSS. Once you get comfortable with these, everything else (layouts, animations, responsive design) becomes way easier to approach.

I'm still learning, but this much I can say — spend time practicing selectors. Open DevTools, inspect elements, try targeting them differently. It helps a lot.

Happy coding! 🚀

This article is part of my Web Dev Cohort 2026 journey. Learning in public, one concept at a time.

If you've ever named a file project_final_FINAL_v3_thisone.zip, congratulations — you've already felt the pain that version control was invented to solve.

The Dark Ages of Code Sharing

Picture this: It's 2008. You're working on a college project with three friends. How do you share code?

Option A: Copy everything to a pendrive, physically walk to your teammate's hostel, and pray they don't overwrite your changes.

Option B: Email zip files back and forth with subject lines like "latest code plz check" and "RE: RE: RE: updated version."

Option C: Create a shared folder with filenames like:

project/
├── main.py
├── main_backup.py
├── main_old.py
├── main_final.py
├── main_final_v2.py
├── main_DONT_DELETE.py
└── main_final_ACTUALLY_WORKING.py

Sounds ridiculous? This was genuinely how people collaborated on code before version control became mainstream.

The Real Problems We Faced

1. The Overwriting Nightmare

Rahul copies the code to his pendrive on Monday. Priya does the same. Both work over the weekend. On Monday, whoever copies their version back last wins — and the other person's work just... vanishes. No merge. No warning. Just gone.

2. "Who Broke the Code?"

The project was working yesterday. Today it crashes. Nobody knows who changed what. Everyone points fingers. Classic team dynamics, zero accountability trail.

3. No Going Back

Remember when the login feature worked perfectly two weeks ago? Too bad you saved over it seventeen times since then. That working version? Lost forever in the void of final_final_v4.py.

4. The Collaboration Bottleneck

Only one person could realistically work on a file at a time. Want to parallelize work? Good luck merging two completely different versions of the same file manually at 2 AM before the submission deadline.

A Simple Visual Comparison

Without Version Control:

Developer A ──[pendrive]──> Shared Folder <──[pendrive]── Developer B
                                 │
                                 ▼
                    🔥 Chaos. Overwrites. Tears. 🔥

With Version Control:

Developer A ─────┐
                 │
Developer B ─────┼──> Central Repository ──> Complete History
                 │         │
Developer C ─────┘         ▼
                    ✓ Every change tracked
                    ✓ Easy merging
                    ✓ Full accountability

Why Version Control Became Non-Negotiable

Modern software isn't built by one person in a garage anymore. You have teams across time zones, hundreds of files, and features being built simultaneously. The pendrive approach doesn't scale. It never did, honestly — we just didn't have better options.

Version control systems like Git solved every problem I mentioned:

• Track every change — See exactly what changed, when, and who did it

• Work in parallel — Multiple developers can work on the same codebase without destroying each other's work

• Roll back anytime — That feature you broke? Revert to yesterday's version in seconds

• Branching — Experiment freely without touching the working code

The Bottom Line

Version control isn't just a "nice to have" skill anymore. It's as fundamental as knowing how to write code itself. Every tech company expects it. Every open-source project uses it. And once you've used Git properly, you'll wonder how anyone ever survived the pendrive era.

So the next time you're tempted to create final_v2_LATEST_USE_THIS.zip, remember: there's a better way. And it's been around for decades.

Currently learning web development and documenting my journey. If you found this helpful, let's connect!

When I first heard about cURL, I thought it was some fancy developer tool that would take me weeks to understand. Turns out, I was wrong. It's actually one of the simplest and most useful tools I've picked up in my web development journey. If you're just starting out, this guide is for you.

First Things First: What Even is a Server?

Before we jump into cURL, let's quickly understand why it exists.

Whenever you open a website, your browser is actually sending a message to a computer somewhere in the world called a server. This server holds all the website data and sends it back to you. Think of it like ordering food at a restaurant — you (the client) ask the waiter (your request), and the kitchen (server) prepares and sends back your meal (response).

You (Browser) → Request → Server → Response → You see the website

This back-and-forth happens every single time you load a webpage, submit a form, or scroll through your social media feed.

So What is cURL?

cURL (short for "Client URL") is a command-line tool that lets you send requests to servers directly from your terminal. No browser needed.

That's it. Seriously.

Instead of opening Chrome and typing a URL, you can just open your terminal and type a cURL command. The server doesn't care whether the request comes from a browser or from cURL — it just responds.

Here's a simple way to visualize it:

┌─────────────┐                    ┌─────────────┐
│   Browser   │ ──── Request ────► │   Server    │
└─────────────┘ ◄─── Response ──── └─────────────┘

        vs.

┌─────────────┐                    ┌─────────────┐
│    cURL     │ ──── Request ────► │   Server    │
│ (Terminal)  │ ◄─── Response ──── └─────────────┘
└─────────────┘

Both do the same thing. cURL just gives you more control and doesn't render pretty HTML.

Why Should You Even Care About cURL?

Good question. Here's why I started using it:

1. Testing APIs without writing code — When you're building a backend, you want to quickly test if your endpoints work. cURL lets you do that in seconds.

2. Debugging — Sometimes things break. cURL helps you see exactly what's being sent and received, with no browser magic hiding stuff from you.

3. Automation — You can put cURL commands in scripts and automate repetitive tasks.

4. It's everywhere — cURL comes pre-installed on most systems (Mac, Linux, even Windows now). You'll see it in documentation, tutorials, and Stack Overflow answers constantly.

Making Your First cURL Request

Okay, enough theory. Let's actually do something.

Open your terminal and type:

curl https://example.com

Hit enter. You should see a bunch of HTML printed on your screen. That's the webpage! You just fetched it without opening a browser.

Pretty cool, right?

Understanding the Request and Response

When you run that command, here's what actually happens:

Your Request:

• You're sending a GET request (the default)

• To the URL https://example.com

• Asking the server: "Hey, give me whatever you have at this address"

The Response:

• The server sends back HTML content

• Along with a status code (like 200 for success)

• And some headers (metadata about the response)

To see the status code and headers, add the -i flag:

curl -i https://example.com

Now you'll see something like:

HTTP/2 200
content-type: text/html; charset=UTF-8
...

<!doctype html>
<html>
...

That 200 means everything went fine. You might also see 404 (not found) or 500 (server error) — these status codes are super important for debugging.

Using cURL to Talk to APIs

This is where cURL really shines. APIs are basically servers that return data (usually JSON) instead of HTML.

Let's try fetching some fake user data:

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

You'll get back something like:

{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "Sincere@april.biz"
  ...
}

That's actual data you can use in your applications!

GET vs POST

There are different types of requests. The two most common ones:

• GET — Fetching data (what we've been doing)

• POST — Sending data to create something new

Here's a simple POST example:

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

Breaking it down:

• -X POST tells cURL we're sending a POST request

• -H adds a header (telling the server we're sending JSON)

• -d is the data we're sending

The server will respond confirming our "post" was created.

Where cURL Fits in Backend Development

Here's a simple diagram of where cURL helps:

┌─────────────────────────────────────────────────────────┐
│                  Your Development Flow                  │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   Write Code → Test with cURL → Debug → Fix → Repeat   │
│                      ▲                                  │
│                      │                                  │
│            Quick feedback loop!                         │
│                                                         │
└─────────────────────────────────────────────────────────┘

Instead of building a whole frontend just to test if your API works, you fire off a cURL command and instantly know.

Common Mistakes Beginners Make (Including Me)

Let me save you some frustration:

1. Forgetting the protocol

# Wrong
curl example.com

# Right
curl https://example.com

Always include http:// or https://.

2. Not escaping special characters

If your data has spaces or special characters, wrap it in quotes properly.

3. Missing Content-Type header for POST requests

When sending JSON, always tell the server:

-H "Content-Type: application/json"

4. Copy-pasting commands without understanding them

We've all done it. But take a moment to understand what each flag does. It'll save you hours of debugging later.

5. Ignoring the response status code

Just because you got a response doesn't mean it worked. Always check if it's a 200, 201, or something else.

Wrapping Up

cURL might seem intimidating at first, but it's really just a way to send messages to servers without a browser. Start simple — fetch a webpage, then try an API, then experiment with POST requests.

The more you use it, the more natural it becomes. And honestly, once you get comfortable with cURL, you'll wonder how you ever tested APIs without it.

Happy coding! 🚀

This article is part of my learning journey in the Web Dev Cohort 2026. If you found this helpful, feel free to connect!

Ever wondered what happens in those few milliseconds between typing "google.com" and the page actually loading? I did too, and honestly, it blew my mind when I finally understood it. Let me take you through what I learned about DNS — the unsung hero of the internet.

How Does a Browser Know Where a Website Lives?

Here's a question that got me curious: when you type a website address, how does your browser actually know where to go? It's not like the internet has a GPS, right?

Well, kind of — it does. It's called DNS, which stands for Domain Name System.

Think of DNS as the internet's phonebook. Back in the day, if you wanted to call someone, you'd look up their name in a phonebook to find their number. DNS does exactly that — it translates human-friendly names like example.com into computer-friendly addresses like 192.168.1.1.

Without DNS, we'd all be memorizing strings of numbers to visit websites. No thanks.

Why Do We Need DNS Records?

So DNS is a phonebook, cool. But a phonebook isn't just one giant list — it has structure. Similarly, DNS uses different types of records to store different kinds of information about a domain.

Need to know the IP address? There's a record for that. Need to know where to send emails? Different record. Need to verify you own the domain? Yep, another record.

Each record type solves a specific problem. Let's go through them one by one.

NS Record: Who's in Charge Here?

NS stands for Name Server.

Imagine you want to find someone's address, but first you need to know which phonebook to look in. NS records tell the internet: "Hey, if you want information about this domain, go ask these servers."

For example, when you buy a domain from a registrar like GoDaddy or Namecheap, they set up NS records pointing to their nameservers. If you later move to Cloudflare, you change the NS records to point to Cloudflare's servers instead.

In simple terms: NS records say "this server is responsible for answering questions about this domain."

A Record: The Main Address

The A Record is probably the most important one. The "A" stands for Address.

It maps a domain name directly to an IPv4 address — that's the classic format like 93.184.216.34.

When you type mywebsite.com and hit enter, the browser eventually asks: "What's the A record for this domain?" The answer is an IP address, and that's where your browser goes.

Real-life analogy: If your domain name is like your name, the A record is your home address. Simple.

AAAA Record: The Newer, Longer Address

As the internet grew, we started running out of IPv4 addresses (there are only about 4 billion possible combinations). Enter IPv6 — a newer format with way more possible addresses.

An IPv6 address looks something like this: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Yeah, it's long.

The AAAA record (pronounced "quad-A") maps a domain to an IPv6 address. It does the same job as an A record, just for the newer address format.

Why four A's? IPv6 addresses are four times longer than IPv4, so... four A's. Engineers can be funny sometimes.

CNAME Record: The Nickname

CNAME stands for Canonical Name, but I like to think of it as the "alias" or "nickname" record.

Instead of pointing to an IP address, a CNAME points one domain name to another domain name.

Let's say you have:

• mywebsite.com → points to 192.168.1.1 (A record)

• www.mywebsite.com → points to mywebsite.com (CNAME)

So when someone visits www.mywebsite.com, DNS first resolves it to mywebsite.com, then resolves that to the IP address.

Why is this useful? If your IP changes, you only update one A record. All the CNAMEs automatically follow along.

Common confusion: A records point to IP addresses. CNAMEs point to other domain names. Don't mix them up!

MX Record: Where Do Emails Go?

MX stands for Mail Exchange.

When someone sends an email to hello@mywebsite.com, how does their email server know where to deliver it? It looks up the MX record.

MX records point to the mail servers responsible for receiving emails for your domain. They also have a priority number — if the primary mail server is down, email gets routed to the backup.

Analogy: If A records are your home address, MX records are like your post office address. Different purpose, different destination.

Note: MX is for email routing, NS is for DNS authority. They're completely different things, even though both point to servers.

TXT Record: The Sticky Note

TXT records are the most flexible. They let you attach arbitrary text to your domain.

"Why would I need that?" Great question. Here are common uses:

1. Domain verification: Google, Microsoft, and others ask you to add a specific TXT record to prove you own the domain.

2. Email security: Records like SPF, DKIM, and DMARC (don't worry about these names yet) use TXT records to prevent email spoofing.

3. General notes: Sometimes you just need to store some information.

Think of it as: A sticky note on your domain that anyone can read.

How It All Comes Together

Let's see how a real website might use all these records together.

Imagine I'm setting up coolproject.dev:

When someone visits my site, here's what happens:

1. Browser asks: "Who handles DNS for coolproject.dev?" → NS record answers

2. Browser asks that nameserver: "What's the IP?" → A/AAAA record answers

3. Browser connects to that IP and loads the website

When someone emails me:

1. Their email server asks: "Where do I send emails for this domain?" → MX record answers

2. Email gets delivered to Zoho's servers

Everything works together like a well-organized system.

Wrapping Up

DNS might seem complicated at first, but once you break it down record by record, it starts making sense. Here's the quick recap:

• NS: Who's responsible for this domain's DNS

• A: Domain → IPv4 address

• AAAA: Domain → IPv6 address

• CNAME: Domain → Another domain name

• MX: Where to send emails

• TXT: Extra info and verification

The next time you visit a website, remember — there's a whole system of records working behind the scenes to get you there in milliseconds.

If you're just starting out with web development like me, understanding DNS is a superpower. It'll save you hours of confusion when you're deploying your first project and wondering why your domain isn't working.

Happy coding! 🚀

This article was written as part of my Web Dev Cohort 2026 journey. If you found it helpful, let me know!

Congratulations—you just experienced Git.

No, seriously. That flow—from casually participating, to getting ready, to creating a permanent record, to sharing it with others—is exactly how Git works. And by the end of this article, you'll understand version control so intuitively that you'll never forget it.

But first, let me tell you a secret about learning Git that most tutorials get wrong.

The Secret: Git Commands Are Just English Verbs

Most beginners try to memorize Git commands like magic spells. This is painful, and it doesn't work.

Here's the thing: Git's creator, Linus Torvalds, designed these commands to be intuitive. In a 2025 interview celebrating Git's 20th anniversary, Torvalds explained his core philosophy:

"I kind of compare it to Unix. Unix has a core philosophy of everything is a process, everything is a file, you pipe things between things... I think Git has some of the same kind of fundamental core simplicity to the design." — Linus Torvalds, GitHub Blog Interview, April 2025

Git commands aren't arbitrary. They're verbs that describe exactly what they do:

• git add → adds files to the staging area

• git commit → commits to your changes

• git push → pushes your work somewhere else

• git pull → pulls others' work to you

• git reset → you’re moving pointers to different snapshots

Once you see this pattern, you stop memorizing and start reasoning. That's the goal of this article.

What is Git?

Git is a distributed version control system—a fancy way of saying it's a time machine for your code.

Think of it like a save game system. When you're playing a video game, you save your progress at important moments. Mess up badly? Load a previous save. Want to try a risky strategy? Create a new save file first. Git works exactly the same way for your projects.

The "distributed" part means every developer has a complete copy of the entire project history. You're not dependent on a central server. You can work offline, make saves (commits), experiment freely, and sync up later.

Why Developers Use Git

Git solves real problems that every developer eventually faces:

Collaboration without chaos. Without version control, whoever saves last wins, and everyone else's work vanishes. Git lets multiple people work on the same project simultaneously, then intelligently combines everyone's changes.

Safe experimentation. Want to try a completely different approach? Create a separate branch, experiment freely, and either merge your success back or delete your failed experiment. Your stable code remains untouched.

A complete history of everything. Three months from now, when you're wondering "why did I write this code?", you can look through the history and see exactly what changed, when, and why.

Working offline. Unlike tools requiring constant internet, Git works entirely on your machine. Commit changes on an airplane, sync up later.

Git Basics: Core Terminology (The Wedding Edition)

Here's where our Indian wedding analogy becomes genuinely useful. Let me introduce you to Git's core concepts through an experience you can actually picture.

Repository (the wedding venue) — The entire wedding venue with all its areas, activities, and memories is your repository. It contains your project files plus the complete history of everything that's happened. When you run git init, you're essentially setting up the venue.

Working Directory (roaming the venue) — You're at the wedding, doing your thing. Eating at the chaat counter, catching up with cousins, judging the DJ's playlist. You're participating, but nothing is officially recorded yet. In Git, this is where you edit your files freely, basically your working directory.

Staging Area (walking to the photo stage) — You've decided it's time for the official photo. You fix your outfit, check your hair, and walk toward the stage. You're prepared to be photographed, but the photo hasn't been clicked yet. This is the staging area—your changes are ready to be committed, but not yet saved permanently. This is what happens when you do git add files you want to save permanently in Git tracking are added here.

Commit (the photographer clicks) — You step onto the stage. The photographer counts down. Click. That moment is now permanently documented. This photo will exist in the wedding album, in the WhatsApp group, probably in next year's calendar. A git commit is exactly this—a permanent snapshot that says "this happened."

Branch (different tracks at the wedding) — Every big wedding has multiple things happening simultaneously. The youngsters are on the dance floor. The elders are discussing whose kid got into which IIT. The kids are running around playing. These are different "branches" of the same event happening in parallel. In Git, branches let you work on different features without affecting the main project.

HEAD (your current location) — Simply "where you are right now." Are you at the food stall? The dance floor? The stage? HEAD is your current position in the project's timeline.

Merge (the grand family photo) — Eventually, everyone comes back together for the family photo. The dancers, the elders, the kids—all merging into one frame. In Git, merging combines changes from different branches back into one.

The Mental Model: How Changes Flow

Before learning commands, picture this flow:

Working Directory  →  Staging Area  →  Local Repository  →  Remote Repository
   (roaming the       (walking to      (photo clicked,      (shared on family
    wedding venue)      the stage)      in the album)         WhatsApp)

You participate in the wedding (make changes). You get ready and approach the stage (stage your changes). The photographer clicks (commit). Then you share with the extended family (push to remote).

Every Git command either moves your changes along this pipeline or helps you see what's happening at each stage.

Essential Git Commands

Now let's learn the commands. Remember: these are English verbs telling Git what to do.

git init — "Initialize a new repository"

This creates a new Git repository in your current folder. It's how you set up the venue.

cd my-portfolio-website
git init

Git creates a hidden .git folder that stores all the version control magic. Run this once per project.

git clone — "Clone an existing repository"

If a repository already exists somewhere (like on GitHub), this creates a complete copy on your machine, including the entire history.

git clone https://github.com/username/project-name.git

git status — "What's the current status?"

This is your go-to command for understanding what's happening. Which files changed? What's staged? Which branch are you on?

git status

Interestingly, Torvalds admitted he didn't even include git status in his initial version—he didn't think he needed it. In his 2025 interview, he noted that the command naming caused "flame wars" early on because he deliberately chose different names than CVS (the tool Git was replacing) since he "didn't like CVS very much."

Run git status constantly. It's your project's pulse.

git add — "Add this to the staging area"

This moves changes from your working directory to the staging area—you're getting ready for the official photo.

git add index.html           # Stage a specific file
git add .                    # Stage all changed files

git commit — "Commit these changes permanently"

This creates a snapshot of everything currently staged. The photographer clicks. Always include a descriptive message.

git commit -m "Add navigation bar to homepage"

Your commit message should explain what you did and ideally why. Future you will be grateful.

git log — "Show me the history log"

This displays the history of commits—your project's photo album.

git log
git log --oneline    # Compact view

git branch — "Show or create branches"

Used alone, this lists all branches. With a name, it creates a new one.

git branch                    # List all branches
git branch feature-contact    # Create a new branch

git checkout — "Check out (switch to) this branch"

This switches you to a different branch or commit.

git checkout feature-contact    # Switch to an existing branch
git checkout -b new-feature     # Create AND switch in one step

git merge — "Merge this branch into mine"

When you've finished work on a branch and want to incorporate those changes into another branch, you merge.

git checkout main              # Switch to the destination branch
git merge feature-contact      # Merge the feature branch into it

git push — "Push my commits to the remote"

This uploads your local commits to a remote repository (like GitHub), sharing them with others.

git push origin main

This is you sharing the wedding photos on the family WhatsApp group.

git pull — "Pull the latest changes from the remote"

This downloads commits from the remote repository and merges them into your current branch.

git pull origin main

Always pull before starting work to make sure you have everyone else's latest changes.

A Typical Workflow (Wedding Style)

Let's tie everything together with a realistic scenario. You're building a portfolio website and want to add a contact page.

Arrive with the latest updates. Before doing your own thing, see what everyone else has been up to.

git pull origin main

Find your own space to work. Don't cause chaos at the main stage. Create your own branch.

git checkout -b add-contact-page

Do your work. Create contact.html, add styles, update the navigation. You're enjoying the wedding.

Check yourself before the photo. See what you've been up to.

git status

Walk to the stage. Stage your changes.

git add contact.html styles.css index.html

Click! Take the photo. Commit with a clear message.

git commit -m "Add contact page with form and update navigation"

Join the family photo. Merge your work back to main.

git checkout main
git merge add-contact-page

Share with everyone. Push to the remote repository.

git push origin main

That's a complete professional Git workflow.

Final Thoughts

Torvalds once wrote in an email: "There are too many messy SCMs (Source Code Management) out there that do not have a 'philosophy.' Dammit, I'm not interested in creating another one. This thing has a mental model, and we keep to that model."

That mental model is what makes Git learnable. The commands are verbs. The concepts map to real experiences. And once you see the pattern, you stop memorizing and start understanding.

Start simple. Use git status constantly. Make small, frequent commits with clear messages. Create branches for experiments. And when something goes wrong—because it will—remember that Git almost never actually deletes anything. Your work is usually recoverable.

The best way to learn Git is to use it on a real project. Create a repository for your portfolio, your notes, or a simple practice project. Make commits. Create branches. Break things and fix them.

Before long, these commands will feel as natural as finding the food counter at any wedding venue.

Happy coding! 🎉

References

1. Torvalds, Linus. Interview with Taylor Blau. "Git turns 20: A Q&A with Linus Torvalds." GitHub Blog, April 7, 2025. https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/

2. Torvalds, Linus. "Re: Handling renames." Git Mailing List, April 14, 2005. https://public-inbox.org/git/Pine.LNX.4.58.0504141102430.7211@ppc970.osdl.org/

3. "Git - gitglossary Documentation." Git Official Documentation. https://git-scm.com/docs/gitglossary