Introduction
Commitment is a funny thing.
Some people date for years before making it official. Some rush into relationships they regret two weeks later. And then there are those people who keep saying, “Let’s just see where this goes,” until everyone involved is emotionally exhausted.
Believe it or not, Git has the exact same personality.
If you’ve never heard of Git before, think of it as a really smart time machine for your code. It remembers every meaningful change you make, lets you revisit older versions when things go wrong, and makes it possible for multiple developers to work on the same project without accidentally overwriting each other’s work. In short, Git is a version control system and one of the most important tools you’ll use as a developer.
But Git doesn’t commit to every little change you make.
Every time you edit a file, Git looks at your changes and asks, “So… are we serious, or are we just experimenting?” If you’re not ready to commit, your changes wait patiently in the staging area,the software equivalent of “It’s complicated.” If you are ready, Git wraps everything up into a commit: a permanent promise that says, “Yes, I meant to do this.”
The problem is that most beginners are taught Git like they’re preparing for a spelling bee.
git add
git commit
git push
Memorize the commands.
Don’t ask questions.
Hope nothing catches fire.
Then, the first time they accidentally commit the wrong files, forget to stage something important, or stare at git status like it’s judging their life choices, panic sets in.
Here’s the secret: Git isn’t complicated because the commands are difficult. It’s confusing because no one explains why they exist.
So in this article, we’re going to stop memorizing magic words and start thinking like Git. We’ll open the mysterious staging crate, decide which changes deserve commitment, rescue a few questionable life decisions, and discover why version control is less about remembering commands and more about making good choices.
Because in Git-as in relationships not everything you change deserves a lifelong commitment.
Episode 1: "So... What Are We?" (git init)
Picture this.
You've met someone amazing. You've exchanged numbers. You've talked for hours. You've even started imagining your future together.
But then a friend asks,
"Wait... are you two actually together?"
Cue the awkward silence.
Because until someone makes it official, you're just... existing in each other's lives.
Your project has the same identity crisis.
You create a new folder. You add a few files. Maybe you've already written hundreds of lines of code. It looks like a software project, smells like a software project, and behaves like a software project.
Git, however, looks at it, shrugs, and says,
"I've literally never seen this project before."
That's where this little command changes everything.
git init
The moment you hit Enter, your project finally introduces itself.
Git quietly creates a hidden folder called .git a place you'll almost never open but one you'll rely on every single day.
Think of it as the relationship archive.
Every promise you keep (commits), every detour you take (branches), every reunion after a disagreement (merges), and every embarrassing decision you'd rather pretend never happened... Git stores it all in there.
It's basically that friend who remembers everything.
"Remember that tiny CSS change you made three weeks ago at 2:17 a.m.? Yeah... I still have it."
And if one day you decide to delete the .git folder?
Congratulations.
You didn't delete your project.
You just convinced Git that the two of you never met.
Episode 2: The Honest Bestie (git status)
Every relationship has that one best friend.
The one who somehow knows everything before you tell them.
"Girl... I saw what happened."
"You're leaving out the important part."
"Who exactly is this?"
They're not being nosy.
They're just trying to save you from making questionable decisions.
Git is that best friend.
Ever since you made things official with git init, Git has been quietly paying attention to your project. It isn't changing anything or making decisions for you it simply watches, remembers, and waits for your next move.
So naturally, the first thing you should ask your bestie is,
"Okay... what's the situation?"
git status
Git takes one look around your project and gives you the unfiltered truth.
"I noticed you've brought some new people into your life..."
"...care to introduce me?"
Those red filenames aren't errors.
They're untracked files files that Git has noticed but hasn't officially been introduced to yet.
Think of it this way.
You've started hanging out with new friends, but you've never brought them around your bestie. So when your best friend sees them for the first time, they're naturally like,
"Wait... who are these?"
Until you make those introductions, Git won't remember those files or include them in your project's history. If they disappear tomorrow, Git can't help you because, as far as it's concerned...
"I've never met them."
Now, let's address the one person who always shows up uninvited.
Take a look at the list again.
See .ipynb_checkpoints/?
If you use Jupyter Notebooks, you've probably met this little troublemaker. Every time you save your notebook, Jupyter quietly creates checkpoint files behind the scenes as a backup.
It's useful.
It's harmless.
But it has absolutely no business following you to GitHub.
It's like bringing your best friend to meet your family... and they show up with their cousin, their neighbor, and someone's emotional support hamster.
Nobody asked for all that.
Episode 3: "Before You Make It Official..." (git add)
You know what happens after you've introduced someone to your best friend?
The interrogation begins.
"So... do you actually like them?"
"Are they staying?"
"Should I bother learning their name?"
"Is this another one of your 'it's different this time' situations?"
Your bestie isn't being dramatic.
They're just trying to figure out who deserves a permanent place in your life.
Git has reached that exact moment.
In the last episode, git status showed Git everyone hanging around your project. It noticed the new files, gave you the side-eye, and asked,
"Okay... who exactly are these people?"
Now it's waiting for your answer.
This is where the staging area comes in.
Think of it as the beautifully crafted wooden crate sitting on your desk.
It's not the commitment box.
Not yet.
It's simply where you place the files you're considering committing.
Inside the crate are envelopes labelled:
- Maybe later
- Not ready yet
Sound familiar?
That's because staging isn't commitment.
It's intention.
It's you telling Git,
"These are the changes I'm thinking about making official."
Maybe you're confident and want to stage everything.
git add --all
Git happily picks up every new file, every modified file, and every deleted file, placing them neatly into the staging crate.
You'll also see developers use the shorter version.
git add -A
Same result.
Just fewer keystrokes.
Now suppose you're standing inside your project and simply want Git to gather everything from right here.
That's where the famous little dot comes in.
git add .
That tiny . simply means,
"Start from this folder and bring everything below it."
If you're already at your project's root directory, git add . will usually give you the same result as the previous commands.
Now imagine your bestie peeks inside the staging crate.
"Okay... these are the people you're serious about?"
You nod.
Your bestie smiles.
"Cool."
"Just remember... putting them in the crate doesn't mean you're engaged."
Exactly.
Nothing has been committed yet.
The letters are written.
The envelopes are packed.
The crate is full.
But the promise hasn't been made.
That... happens in the next episode.
Episode 4: The Plot Twist - "Wait... They're Coming Too?"
You've spent all this time deciding who belongs in the staging crate.
Your bestie helped.
The letters are neatly packed.
Everything looks perfect.
So, just before making the biggest commitment of your Git journey, you ask one last question.
"Bestie... can you check the crate one more time?"
Git happily obliges.
git status
Everything is green.
At first, you're relieved.
"Yes! We did it!"
Then your bestie squints at the list.
"...Hold on."
"Why is that coming with us?"
You lean over the crate.
Inside, alongside your Python scripts and notebooks, you spot...
- A massive software installer ZIP file.
- An MP3 music file.
-
.ipynb_checkpoints/quietly pretending it belongs.
Awkward.
This is what happens when you stage everything without checking what's inside the crate.
It's the Git equivalent of sending wedding invitations to everyone in your contacts list...
...including your ex.
...your nail-tech.
...and the plumber who fixed your sink three years ago.
Technically, they'll all show up.
But should they?
Absolutely not.
If you commit these files and push them to GitHub, your repository becomes unnecessarily large, cloning takes longer, and anyone reviewing your project will immediately wonder,
"Did they actually mean to include all of this?"
The good news?
Git understands that we all make questionable decisions.
It even gives you a graceful way to unpack the entire staging crate without throwing away your actual files.
git rm -r --cached .
Think of this command as your best friend standing at the door collecting invitations.
"Nope... you're not coming."
"You either."
"Definitely not you."
The files stay safely on your computer.
Git simply removes them from the staging area, giving you the chance to pack the crate again but this time with a little more intention.
Because here's the thing about commitment...
Changing your mind before you make the promise is a lot easier than trying to explain yourself afterward.
Episode 5: "So... Are We Official Now?" (git commit)
The crate is packed.
Your bestie has checked the guest list twice.
The random ZIP file has been politely uninvited.
.ipynb_checkpoints/ finally got the hint.
Everything inside the staging crate is exactly where it should be.
Your bestie looks at you.
"Last chance."
"Are you absolutely sure these are the changes you want to keep forever?"
You take one final look.
You smile.
"Yeah... I'm ready."
This is the moment Git has been waiting for.
git commit -m "First commit"
With a single command, Git carefully closes the staging crate.
It seals every envelope with wax.
It writes today's story into its diary.
And just like that...
Your changes become part of history.
This is called a commit.
Think of a commit as a photograph.
Not of what your project will become...
...but of exactly what it looked like at this very moment.
No matter how many changes you make tomorrow, next week, or six months from now, Git can always return to this snapshot.
That's why commits are so powerful.
They're promises to your future self.
They're your way of saying,
"I know this version works."
"I know why I made these changes."
"If I ever mess things up, I can always come back here."
And before you start thinking,
"Great! My code is finally on GitHub!"
Not so fast.
Your commit lives only on your computer.
It's like writing a heartfelt love letter, sealing it in an envelope, and placing it safely inside your desk drawer.
The promise is real.
It's official.
But nobody else knows about it...
Yet.
Episode 6: The "We Need to Talk" Conversation (git switch, git diff & git restore)
Every healthy relationship has one.
The conversation.
Not the breakup.
Not the proposal.
The one that starts with,
"Can we talk?"
Maybe someone wants to rephrase a promise.
Maybe someone realizes they could have said something better.
Maybe they're just trying to figure things out.
The good news?
In Git, you're allowed to have those conversations without ruining the original relationship.
That's exactly what branches are for.
Think of a branch as an alternate timeline.
Instead of rewriting history, Git lets you create a safe little universe where you can experiment, make mistakes, and change your mind, all without touching your stable project.
So let's create one.
git switch -c remove_promise
Your bestie raises an eyebrow.
"So... you're telling me you're about to edit the promise?"
Relax.
We're not changing the original.
We're just exploring a "What if?" scenario.
Inside our index.html, we tweak the heartfelt letter.
Nothing dramatic.
Just enough to make Git notice.
Before doing anything else, let's ask our honest bestie what they think.
git status
Git immediately notices the change.
"I saw that."
"You changed something... but you haven't told me to remember it yet."
That's all git status is doing.
It's keeping you honest.
Now imagine you stare at your edit for a minute and suddenly think,
"What was I even trying to say?"
We've all been there.
Fortunately, Git doesn't judge questionable decisions.
It simply offers an escape route.
git restore index.html
Think of git restore as crumpling up the draft letter before anyone reads it.
The edits disappear.
Your last committed version remains untouched, as if the conversation never happened.
But let's pretend we actually like our new wording.
How do we see exactly what changed?
That's where git diff becomes your bestie's favorite gossip tool.
git diff index.html
Git opens the receipts.
No guessing.
No "I think I changed this."
Just the facts.
The red line, marked with a -, shows what you're saying goodbye to.
The green line, marked with a +, shows the new version waiting to take its place.
In our case, we upgraded the promise by adding the word "always."
One tiny word.
One huge difference.
And before we make that promise official, Git gives us one final chance to review every single change.
Because the strongest relationships and the strongest codebases aren't built by never making mistakes.
They're built by being able to see exactly what changed before making another commitment.
Episode 7: The Reunion (git merge)
Every couple reaches this moment.
You've had the difficult conversation.
You've rewritten the letter.
You've taken some time apart to figure things out.
Now comes the big question.
"Can we bring this back into the relationship?"
Remember, all of our edits have been living safely on a separate branch. Think of it as taking a weekend getaway to clear your head. The main branch has been patiently waiting at home, completely untouched.
Before the reunion can happen, we need to go back home.
git switch main
Your bestie smiles.
"Welcome back."
Now it's time to bring everything we worked on back into the main story.
git merge remove_promise
Git takes one look at both branches.
Then it shrugs.
"Well... that was easy."
Since nobody touched the main branch while we were away, Git doesn't have to play relationship counselor.
There are no arguments.
No awkward conversations.
No one saying,
"That's not what I meant."
Instead, Git simply moves the main branch forward until it catches up with your new commit.
This is called a fast-forward merge.
Think of it like coming back from a weekend trip.
Your family didn't repaint the house.
Nobody rearranged the furniture.
Everything is exactly where you left it.
So fitting back in is effortless.
Your upgraded promise is now part of the main story, and Git quietly records another successful chapter in its diary.
Your bestie closes the diary with a satisfied smile.
"Perfect."
"Everything is finally where it belongs."
You smile back...
Then your bestie asks one last question.
"...So, are you planning to keep this relationship a secret?"
Because right now, everything we've done exists only on your computer.
Our story is complete.
Our commits are safe.
Our branches are merged.
But the rest of the world still has no idea our project exists.
Let's change that.
Episode 8: Going Public (git push)
So far, our entire love story has been wonderfully... private.
We've met Git.
We've introduced the important files.
We've packed the staging crate.
We've made our commitment.
We've even survived a little relationship drama and reunited stronger than before.
But there's one tiny problem.
Everything we've done still lives only on our laptop.
It's like getting engaged...
...and forgetting to tell your family.
Before we can share our project with the world, Git needs to know where the world is.
So head over to GitHub, create a repository, and copy its URL.
Then introduce your local repository to its new home.
You'll notice we give GitHub a nickname:
origin
Think of it as saving someone's contact in your phone as "Bestie" instead of memorizing their entire phone number.
origin is simply a friendly alias for your GitHub repository, making it much easier to communicate with later.
Now comes the moment we've been building toward.
git push -u origin main
With one command, your local story leaves your laptop for the very first time.
Your commits travel to GitHub.
Your repository finally has an online home.
And your project is no longer just your story.
It's a story others can now see, clone, learn from, and contribute to.
Our relationship is officially public.
But don't get too comfortable...
Because sharing your work with the world introduces a whole new kind of drama.
Pull requests.
Remote repositories.
Authentication.
Merge conflicts.
And teammates who somehow edit the exact same line you were working on.
We'll save that tea for the next chapter.
Top comments (2)
An intuitive narrative
Thank you