DEV Community

Cover image for Git, Explained
Dulaj Thiwanka
Dulaj Thiwanka

Posted on

Git, Explained

#git #beginners #explainlikeimfive #programming

Git is everywhere.
Jobs expect it. Teams depend on it. Tutorials assume you already understand it.

And yet, many developers use Git daily while secretly hoping nothing goes wrong.

This article is not about memorizing commands.
It’s about understanding what Git is thinking, so the commands stop feeling dangerous.

We’ll go slowly. Very slowly. On purpose.

Part 1: Why Git Exists (A Very Human Problem)

whygit

Imagine writing a document over several weeks.

You save versions like:

  • report.docx
  • report_final.docx
  • report_final_v3_REAL.docx

Now imagine three people editing that document at the same time.

That chaos is what Git was built to prevent.

Git exists to:

  • Track changes over time
  • Let multiple people work safely
  • Make mistakes reversible
  • Preserve context (the why, not just the what)

Git is not just backup.
Git is structured memory.

Part 2: The Mental Model That Changes Everything

track

Here’s the idea that makes Git stop feeling random:

Git does not track changes.
Git tracks snapshots.

Every commit is a photograph of your entire project folder at a specific moment in time.

If a file hasn’t changed, Git doesn’t store it again.
It simply points to the previous version.

This is why:

  • Git is efficient
  • Git is fast
  • Git history feels immutable

Once something is committed, it becomes a historical fact.

Part 3: Creating a Repository (Where Memory Begins)

git

git init
Enter fullscreen mode Exit fullscreen mode

This creates a hidden folder called .git.

That folder contains:

  • Every commit
  • Every branch
  • The entire history graph
  • All metadata

Your code files are outside .git.
Your project’s memory lives inside .git.

If .git disappears, Git forgets everything.

Part 4: The Three Places Your Code Can Exist

This is the most important concept in Git.
If you understand this, almost everything else makes sense.

image

1. Working Directory

This is your normal folder.
You edit files here.
Git is watching, but nothing is saved yet.

2. Staging Area (Index)

This is where you tell Git:

“These specific changes are ready to be recorded.”

Not everything. Just what you choose.

3. Repository (Commits)

This is Git’s permanent history.
Once something is here, it’s part of the timeline.

Git never commits directly from your folder.
It commits from the staging area—because intention matters.

Part 5: Asking Git What It Sees

Image

Before running any command, get used to this:

git status
Enter fullscreen mode Exit fullscreen mode

This tells you:

  • What changed
  • What’s staged
  • What’s not tracked
  • What Git is waiting for

If Git ever feels confusing, it’s usually because git status wasn’t read.

Part 6: What git add Really Does

image

git add index.html
Enter fullscreen mode Exit fullscreen mode

This does not mean “save forever”.

It means:

“Take the current version of this file and copy it into the staging area.”

You can still edit the file afterward.
The staged version will not change unless you add it again.

This lets you:

  • Stage only part of your work
  • Create clean, focused commits

Part 7: Committing (Freezing a Moment)

Image

git commit -m "Add homepage layout"
Enter fullscreen mode Exit fullscreen mode

This creates:

  • A snapshot
  • A unique hash (ID)
  • A permanent history point

Commits cannot be edited.
Git does not erase history—it adds to it.

Think of commits as pages in a journal.
You don’t rip out pages. You write new ones.

Part 8: Commit Messages Are for Humans

Image

Bad messages:

fix
update
stuff
Enter fullscreen mode Exit fullscreen mode

Good messages explain intent:

Fix broken layout on small screens
Add input validation for signup form
Refactor auth logic to simplify flow
Enter fullscreen mode Exit fullscreen mode

Your future self will read this.
So will teammates.
Write like you’re explaining your thinking.

Part 9: Reading History Without Fear

Image

git log
Enter fullscreen mode Exit fullscreen mode

Better:

git log --oneline --graph
Enter fullscreen mode Exit fullscreen mode

This shows:

  • Commits as nodes
  • Parent relationships
  • Branch structure

Git history is a graph, not a straight line.
That’s why merges and branches exist.

Part 10: Branches (The Safest Place to Experiment)

Image

A branch is not a copy of your code.

A branch is:

A movable label pointing to a commit

That’s why creating branches is cheap and encouraged.

git checkout -b feature/settings
Enter fullscreen mode Exit fullscreen mode

Now:

  • main stays stable
  • Your work happens safely elsewhere

Each commit moves the branch pointer forward.

Part 11: HEAD (Git’s “You Are Here” Marker)

Image

HEAD simply means:

“This is where you are right now.”

Usually it points to a branch.
Sometimes it points directly to a commit.

Most confusion comes from not knowing where HEAD is.

When lost, ask:

  • What branch am I on?
  • What commit does it point to?

Part 12: Merging (Bringing Work Together)

Image

When a feature is ready:

git checkout main
git merge feature/settings
Enter fullscreen mode Exit fullscreen mode

Git tries to combine histories.

Two common outcomes:

  • Fast-forward merge (simple pointer move)
  • Merge commit (combining branches)

Both are normal.
History shape is a choice, not a mistake.

Part 13: Merge Conflicts (Not Errors)

Image

A conflict means:

“Git can’t decide for you.”

Git stops.
Marks the file.
Waits.

You:

  • Open the file
  • Choose what stays
  • Remove conflict markers

Then:

git add .
git commit
Enter fullscreen mode Exit fullscreen mode

Conflicts are collaboration points, not failures.

Part 14: Working With Other Humans (Remotes)

Image

A remote repository is just another copy of the same timeline.

git push
Enter fullscreen mode Exit fullscreen mode

“I’m sharing my history.”

git fetch
Enter fullscreen mode Exit fullscreen mode

“Show me new history.”

git pull
Enter fullscreen mode Exit fullscreen mode

“Combine their history with mine.”

If you’re unsure, fetch first.
Nothing breaks from fetching.

Part 15: Undoing Mistakes Calmly

Image

Undo local file changes:

git checkout -- file.txt
Enter fullscreen mode Exit fullscreen mode

Undo a commit safely:

git revert <commit>
Enter fullscreen mode Exit fullscreen mode

Revert creates a new commit that cancels the old one.
History remains truthful.

Part 16: Stashing (Hiding Work Temporarily)

Image

git stash
Enter fullscreen mode Exit fullscreen mode

Git hides uncommitted changes.

git stash pop
Enter fullscreen mode Exit fullscreen mode

Git restores them.

Stash is for interruptions, not long-term storage.

Part 17: Rebase (Editing the Story)

Image

Rebase rewrites commits so history looks clean and linear.

Think of it as editing a draft before publishing.

Golden rule:

Never rebase commits others already have

Part 18: Interactive Rebase (Advanced Control)

Image

git rebase -i HEAD~5
Enter fullscreen mode Exit fullscreen mode

This lets you:

  • Combine commits
  • Rename messages
  • Remove mistakes
  • Reorder history

This is how clean histories are made.

Part 19: Reflog (The Panic Button)

Image

git reflog
Enter fullscreen mode Exit fullscreen mode

Git remembers:

  • Every checkout
  • Every reset
  • Every mistake

If you think something is lost, reflog usually knows where it went.

Part 20: Habits That Make Git Pleasant

Image

  • Commit small changes
  • Write clear messages
  • Read git status
  • Don’t force-push shared branches
  • Respect the timeline

Final Thought

Git is strict, not cruel.

It does exactly what you tell it to do.
Nothing more.
Nothing less.

Once you understand snapshots, staging, and history, Git stops being scary and starts being dependable.

And a dependable memory is one of the most powerful tools a developer can have.

Keep committing.

Top comments (0)