Day #5 - Git Basics: Learning to Save, Track, and Undo with Confidence

Table of contents

Hey there! Welcome back — or if this is your first time here, I’m really glad you stopped by.
Lately, I’ve been knee-deep in Linux terminals, scripting odd little automations, containerizing things I didn’t even know could be containerized... you know, the usual DevOps fun. But just last week, a close friend messaged me and said:
“Hey, can you teach me Git? I’ve been thinking of creating projects from my learnings — and Git feels new and… intimidating.”
And honestly? That hit home. Because not too long ago, I was that person.
And just like that, I knew what my next blog had to be.
Because if he’s asking, I’m willing to bet there are plenty of others quietly wondering the same thing — googling weird error messages, copy-pasting random Git commands, and hoping no one asks them what a "commit" actually means.
So friend — if you’re reading this, Welcome aboard. This blog is for you.
(And for anyone who’s ever stared at a Git tutorial thinking, “I’ve heard of Git... but I still don’t really get it,” — this is for you.)
We’re going to take it from the top. Just a calm, beginner-friendly journey through Git and GitHub, what they do, why they matter, and how to actually use them to manage your projects (even if you still feel like a beginner).
Let’s Git started.
Why Git? Let Me Tell You a Story
Okay — so picture this. You’re working as a freelance web developer (maybe even your first real client gig.)
The client sends you a beautifully simple design—elegant, minimal, and perfectly pink. You roll up your sleeves, crack open VS Code, and start building. To keep things tidy, you create a folder on your computer: “Project-X-for-client”
You write all your code in there — HTML, CSS, maybe a bit of JavaScript flair — and when you're done, you upload the website to a server. You proudly share the link with your client and wait for that “Looks great!” reply.
Instead, you get this:
The classic client plot twist.
Client: “Hey, the design looks cool, but can we ditch the pink? I’m feeling something more… lavender.”
Now, you could remind them that pink was in the original design.
You could sigh deeply into your keyboard.
But you're a professional (and maybe a bit of a people-pleaser), so you smile and say:
“Sure, no problem!” 😇
You update the styles, swap pink for lavender, and re-upload the files.
A day later…
Client: “Hmm… the font seems too stiff. Can you make it a bit more whimsical? Maybe even something out of a comic book? You know, like Superman flying across the sky?”
You're not sure what that means. But you try.
At this point, you’re questioning all your life choices — but again, you make the changes, update the project folder, and send over the new link.
Then comes the final boss moment:
“Client: “Actually, after thinking it over, I believe the original pink theme was perfect. Can you revert back to that?”“
You take a deep breath.
Maybe open Spotify. Maybe put on some lo-fi beats to drown your inner scream.
And then — painstakingly — you recreate the original design from memory.
To avoid disasters like this, you start doing what most of us did in the beginning, you create multiple folders for different versions:
And hey — it kind of works.
Until your client wants 35 revisions. Or you accidentally overwrite version 3 with version 5. Or you just can’t remember which one had the Superman font
You need something better.
And Then You Discover Git
This is where Git comes in — like a quiet, reliable assistant who remembers everything.
Every change you make?
Every version of your project?
Every time you fixed or broke something?
Git tracks all of it — automatically and efficiently.
No more folders stacked like a Jenga tower. No more panic when a client changes their mind. No more wondering what changed between version 2 and version 9.
With Git, you get clarity.
And the best part? You don’t need to be a pro developer to use it. You just need to understand why it matters — and that’s exactly what we’re going to do together.
So... What is Git really?
Alright, let’s take a deep breath. You just survived a wild client story, and now you’re probably thinking:
“Okay… so Git helps avoid the folder mess. But what is it, exactly?”
Fair question. Let’s break it down.
Git = Version Control (But Not the Scary Kind)
Git is what we call a version control system — but don't let that term scare you.
Let’s simplify it:
Let’s say you’re playing a tough game — maybe you're fighting a boss.
You defeat the mini-boss, find a cool item, and then... you save the game.
If you mess up 10 minutes later (and you will), you can always go back to that safe spot and try again.
Git does the same thing for your projects. Every time something is working well, you can hit “save” — not just on your computer, but in project history.
These “saves” are called commits in Git-speak. We’ll explore them soon.
You can flip back to earlier pages (versions), see exactly what changed, who changed it (if you’re working in a team), and even rewind if something breaks.
That’s it. That’s the magic.
It’s like having a save game button for your code.
But Wait — It Gets Better
Git also lets you experiment without fear.
Let’s say you want to try adding a fancy animation, or change your homepage layout — but you’re not sure if it’ll turn out well.
With Git, you can create a branch — basically a copy of your project — where you test your idea without touching the original.
It also makes teamwork super smooth — everyone can work on their own branches without stepping on each other’s toes. In short, branches give you a safe, creative sandbox — no fear of breaking anything important!
And Then Comes GitHub
Git tracks all of this locally — meaning on your computer.
But what if you want to:
Share your project online?
Work with a teammate?
Back it up to the cloud?
That’s where GitHub comes in — an online platform where your Git projects can live, collaborate, and grow. We’ll dive into it very soon.
Git vs GitHub: A Simple Analogy
Okay — so now you’ve got a basic idea of what Git is.
It’s your project’s memory. A save-point machine. A way to go back in time or test wild ideas without wrecking the main build.
But then... along comes GitHub — and things get a little fuzzy.
People say Git and GitHub in the same sentence like they’re twins. But are they the same thing?
Short answer:
But they work beautifully together.
Let’s break it down
Think of It Like Email
If you’ve ever used email, this will click:
Git is like the email protocol — the invisible stuff that handles how messages are created and moved.
GitHub is like Gmail, Outlook, or Yahoo — the platform you log into to see, send, and organize everything.
So even though Git works fine on its own, using GitHub makes your life easier, collaborative, and cloud-backed.
Let’s Git Our Hands Dirty
Okay! Enough theory — it’s time to actually try things out.
We’ll start by creating a brand-new project and turning it into a Git repository — one step at a time.
And yes… Linux is back!
There’s no escaping it!
(If you need a refresher, you can always check out my Getting Started with Linux blog.)
Step 1: Create Your Project Folder
First, let’s make a new folder (Linux calls these directories) where we’ll keep our project files.
mkdir project
This just tells Linux:
“Please create a new folder named
project
.”
Now step into that folder using:
cd project
Think of it like walking into a clean, empty room — this is where we’ll build something cool.
Step 2: Initialize Git (The Secret Control Room)
Now for the fun part: telling Git to start watching this folder.
Run:
git init
This command sets up Git in the background and says:
“Hey Git, keep an eye on this folder. I want you to remember every change I make from now on.”
Git responds by creating a hidden folder inside called .git
. That’s where it stores all the behind-the-scenes stuff — your project’s history, settings, logs, and more.
You don’t need to worry about what’s inside .git
just yet. Just know this:
That’s the brain of your Git project.
So… What Just Happened?
Let’s recap the steps:
mkdir project # Step 1: Create a folder for your project
cd project # Step 2: Move into that folder
git init # Step 3: Turn it into a Git repository
That’s it! Git is now silently watching this folder — waiting for you to say:
“Alright Git, I want to save this version of my work.”
We’ll get to how to actually save those changes (called commits) in just a bit.
But the important thing is:
We’ve officially started using Git!
The First Save — Let’s Talk Commits
You’ve created your project folder. You’ve told Git,
“Hey, this is a project I want you to track,”
with thegit init
command.
But right now?
Git is just sitting quietly in the background, arms crossed, observing.
Now let’s do something worth tracking.
Let’s say you make a new file called index.html
. You add some basic HTML:
<!DOCTYPE html>
<html>
<head>
<title>My First Git Project</title>
</head>
<body>
<h1>Hello, world!</h1>
</body>
</html>
Great! You save the file — just like you normally would in any project.
But here’s the surprising part:
Git doesn’t care yet.
It saw the file appear, but it won’t do anything until you explicitly tell it to.
Git is a little like that friend who won’t take any action unless you say,
“Hey, please do this.”
That’s where the next three steps come in:git status
– What’s the current situation?git add
– Tell Git which files to prepare for savinggit commit
– Save the files in a snapshot
git status
: What’s the Situation?
Before we do anything serious with Git — like saving our work or pushing it to GitHub — it’s a good habit to check what’s currently going on inside our project.
That’s where git status
comes in.
Inside your project folder, simply run:
git status
Git will take a look around and say something like:
Untracked files:
index.html
That’s Git’s polite way of saying:
“Hey! I noticed a new file here, but I’m not keeping track of it yet. If you want me to remember it, just let me know.”
Think of this like checking your to-do list before heading out. It tells you what’s changed, what’s missing, and what’s ready to be saved — so there are no surprises later.
You’ll find yourself using git status
a lot. It’s a simple way to stay updated and make sure everything is in order before moving ahead.
git add
: Tell Git What to Remember
Right now, index.html
is just sitting there.
Git has noticed it — like a new guest entering the party — but it’s not doing anything with it yet. It's just observing.
So how do we say:
“Yes Git, this file matters. I want to include it in my next snapshot.”
We run:
git add index.html
Boom. The file is now staged.
But hold on — what exactly is staging?
Let’s picture this:
You're taking a group photo. People are still wandering around, fixing their hair, adjusting outfits. Before you snap the picture, you shout:
“Anyone who wants to be in the photo — come stand here!”
That’s staging.
You’re gathering everyone who wants to be remembered in the next snapshot. Only the ones on stage will be captured when you click the camera.
In Git terms:
git add
→ “Step up to the stage if you want to be saved.”git commit
→ “Smile! This is the moment we’re capturing.”
Simple, right?
And if we’ve got more than one file — say we created multiple pages or tweaked a bunch of code — we don’t want to add them one by one. So we can just say:
git add .
That dot (.
) is Git-speak for:
“Hey, just add everything in this folder that’s new or changed.”
Easy, fast, and super helpful.
git commit
: Lock in the Snapshot
Alright, we’ve staged our files — everyone’s lined up, ready for the photo.
Now it’s time to actually save this moment.
We tell Git:
“Okay, this version of my project? I want to lock it in.”
And we do that by running:
git commit -m "Initial commit: added index.html"
Let’s break that down together:
git commit
→ This is the actual snapshot moment. Git clicks the camera. 📸-m
→ Think of this as the caption for your photo. You’re saying why you took this picture."Initial commit: added index.html"
→ This is your message. Short and sweet, like:"Added login page"
"Fixed image bug on homepage"
"Updated contact form layout"
These little messages might seem optional now — but trust us (and future you will thank you) — they’re life-savers when you're trying to figure out what changed later on.
So with that one command, Git:
✅ Saved the state of everything we staged
✅ Tagged it with a message
✅ Locked it in the timeline
You’ve now made your first official Git commit.
It’s like writing your first entry in a journal — from this point onward, you’ve got a history to fall back on.
If things break later? No panic. You’ve got a clean, working version saved right here — ready to jump back to.
A Quick Recap
Here’s the three-step Git loop you’ll keep using throughout your coding journey:
git status # See what’s changed or new
git add . # Stage everything you want to save
git commit -m "Message describing your work"
You can think of it like saving a video game:
git status
→ Check what’s happened in the gamegit add
→ Decide what progress you want to lock ingit commit
→ Save your progress with a label
The more often you save, the safer your work is.
Wrapping Up — From Clueless to Committed
If you’ve made it this far, give yourself a high five.
We’ve gone from “I’ve heard of Git but don’t really get it” to someone who’s actually using Git — and that’s no small leap.
We didn’t discuss deep and complex concepts like rebasing, forking, or solving hairy merge conflicts. Instead, we walked through the fundamentals — slowly, clearly, and with stories that (hopefully) made it all feel a little less intimidating.
But beyond the commands and tools, I hope you’ve felt something else: confidence.
Confidence that Git isn’t just for advanced developers. It’s for you — the beginner figuring things out one line at a time.
And confidence that when things break (they always do), you’ve got the tools to fix it — or at least the confidence to try.
So here’s to projects you can track, share, and be proud of.
Here’s to building with curiosity — and committing like a pro.
Until next time,
Here’s to your first commit — and many more to come.
Subscribe to my newsletter
Read articles from Arnab directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Arnab
Arnab
Self-taught DevOps learner building in public. Sharing real-time progress, roadblocks, and the random “aha” moments. Hoping my notes help someone else feel less stuck.