Git stores commits as immutable snapshots (photographs) of the entire project, where each commit points to its parent, forming a chain; branches are lightweight 40-byte labels (stickers) that point to commits and move forward with new commits; merge combines two chains by finding the common ancestor and creating a new commit with two parents; rebase creates new commits on top of the latest main by copying changes with new parents; reset moves the branch sticker backward while revert adds a new commit that undoes an old one; detached HEAD means the 'you are here' pin points directly to a commit without a branch, and the reflog keeps a diary of all HEAD positions to recover lost work.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
Git Will Finally Make Sense After This
Added:Be honest. You don't understand Git.
You've memorized it. A little spell book of commands. Pull, add, commit, push.
And as long as nothing goes wrong, the spells work.
But the moment Git says detached head or merge conflict, you feel it. Cold panic.
And somewhere in your past, there's a project you quietly deleted and reccloned because that was easier than understanding what went wrong.
Here's the good news. Git isn't hard.
Git is one picture. And once you see that picture, every command you've memorized becomes obvious and most of the fear just evaporates.
Let me show you.
First, we have to delete the wrong mental model. Most people think git stores changes diffs little patches saying line 12 changed from this to that. It feels right. It's wrong.
Get stores snapshots.
Every commit is a full photograph of your entire project at one moment. Not the difference since last time. The whole thing. When you commit, get photographs every file and files the photo away forever.
And here's the trick that makes that cheap. If a file didn't change, Git doesn't copy it again. The new snapshot just points at the old file. Same content, same fingerprint stored once.
So what's in a commit? Really? Three things. The snapshot, some metadata, who, when, why, and one crucial arrow, a pointer to the commit that came before it.
its parent.
That arrow changes everything. Snapshot points to parent, which points to its parent, all the way back to the very first commit.
Your history isn't a list of changes.
It's a chain of photographs, each one holding hands with the one before.
And each commit gets a name, that big ugly hash. The hash is computed from the content.
Change anything, one bite, one character, and the hash changes.
That's why commits are immutable. You can't edit a commit. You can only take a new photograph.
Now, the part that breaks people's brains in the best way. What is a branch?
You probably imagine a branch as a copy of your code, a parallel folder somewhere.
It's not. A branch is a sticker, a tiny label, literally a 40 byt file that says main points at commit A.
That's it. That's the whole branch. When you create a branch, Git doesn't copy anything. It writes one new sticker pointing at the same commit. Instant, free. And when you commit, Git takes the new photo and slides the sticker forward onto it. The branch you're on follows you automatically.
One more sticker matters. Head. Head is the you are here pin. It usually points at a branch and the branch points at a commit. Check out a different branch.
You just moved the pin.
So now merge. You branched off, made commits, and Maine moved on without you.
Two chains, one shared ancestor.
The graph literally forked.
Merging is git saying find the common ancestor, combine both sets of work and take a new photograph, a special one with two parents.
Two arrows going back, one to each chain. The fork closes into a diamond.
And if main never moved while you worked, then there's nothing to combine.
Git just slides the main sticker forward to your commit. That's a fast forward.
The anti-limax merge. No new photo needed.
A conflict, by the way, is not an error.
It's Git being honest. Both photographs changed the same line, and a tool refuses to guess which one you meant.
You decide. Commit. Done.
Rebase has a scary reputation.
Watch how boring it actually is.
Rebase says, "Take my commits and refograph them one by one on top of the latest main."
Remember, commits are immutable. So, Git can't move them. It makes copies. Same changes, new parent, and therefore new hashes.
The old commits are abandoned. Your branch sticker moves to the new copies.
The fork disappears. History becomes one clean, straight line.
And that's exactly why the golden rule exists. Never rebase commits other people already have. You didn't move the commits, you replaced them. Your teammates are still holding arrows to the old ones, and now their history and yours disagree.
Two ways to undo, and now you can see the difference.
Reset moves the sticker. reset backward three commits and your branch label just slides back three photos. The commits in front aren't deleted. They're still there, just unlabeled.
That's all reset is relocating a sticker plus deciding what happens to your working files. That's the soft, mixed, and hard part.
Revert doesn't move anything backward.
It takes a new photograph that undoes an old one and adds it to the front of the chain.
History grows. Nothing is rewritten.
That's why revert is the safe undo on shared branches. You're adding, not erasing. And now the error that scares everyone. Detached head. Ready?
It means the you are here pin is pointing directly at a commit instead of at a branch.
That's it. You checked out an old photo to look around and Git is just telling you no sticker will follow you if you commit here. Want to keep work you do there? Put a sticker on it. Create a branch. Done. It was never an emergency.
One last secret and it's the one that kills the fear for good.
Git keeps a diary of every place Head has ever been. It's called the ref log.
botched a rebase hard reset past something you needed. The photos still exist. Ref log shows you where they are and a sticker brings them back. In Git, it is genuinely hard to destroy work you've committed. The commits are there.
You just have to point at them.
So, here's the shift. Stop asking what command do I type. start asking where are the photographs and where are the stickers.
Every git command merge, rebase, reset, cherrypick, all of it is just moving stickers and taking photos on one graph.
Read the picture and the command chooses itself.
Three things to keep.
One, commits are snapshots, not diffs.
Immutable photographs, each pointing at its parent.
Two branches are stickers, 40 bytes.
Creating one cost nothing and they move.
The photos don't.
Three, ref log means committed work is almost never lost.
Stop deleting the folder.
That's the picture. One graph, photos, and stickers. And Git finally makes sense.
If this clicked, like and subscribe.
Next up, more of the tools you use everyday actually explained.
Related Videos

TOP 15 Data compression Interview Questions and Answers 2019 Part-2 | Data compression | Wisdom jobs
wisdomjobs
281 views•2019-06-28

CTS 158: 802.11w Management Frame Protection
ClearToSend
4K views•2019-02-04

NDSS 2019 Send Hardest Problems My Way: Probabilistic Path Prioritization for Hybrid Fuzzing
NDSSSymposium
496 views•2019-04-02

How realistic is Cities: Skylines?
CityBeautiful
159K views•2019-02-14

GUIs & TUIs: Choosing a User Interface for Your Python Project | Real Python Podcast
realpython
2K views•2025-04-04

The OSI Model - Explained by Example
hnasr
225K views•2019-05-12

Cloud Computing - Introduction
elithecomputerguy
98K views•2019-10-07

From Traveler's Dilemma to Dynamic Routing | Demystifying Networking
IITBombayJuly
5K views•2019-08-04
Trending

WOW! Judge TURNS THE TABLES on Trump in His OWN $10B LAWSUIT!!!
MeidasTouch
197K views•2026-07-23

Playstation NO DISC/NO BUY Fight Is Over...
DavidJaffeGames
4K views•2026-07-23

Steam and Xbox Just Dropped The Hammer On PlayStation
OhNoItsAlexx
9K views•2026-07-23

Americans Confused in Australia for 17 Minutes Straight
IWrocker
17K views•2026-07-23