Git is Not Magic

Up until now, our timelines were… peaceful.

We clicked photos.
We labeled albums.
We even shared them with others.

Sure, there were branches and parallel stories, but everything made sense.

And then one day, Git looked at us and said:

“These timelines don’t line up.”

This is the part where most people panic.
This is also the part where Git suddenly feels like magic again.

So let’s slow down, because this is where Git actually becomes most honest.

When Timelines Drift Apart

Imagine two people working on the same photo album.

You took a few new photos last night.
Meanwhile, someone else added their own photos to the shared album.

Both stories are valid.
Both timelines make sense on their own.

The problem is not that someone made a mistake.

The problem is that the stories evolved independently.

This is what Git calls a divergent timeline, and it’s not an error.
It’s just reality.

Do You Know What Changed While You Were Gone?

In the last part, we talked about pushing your photos to a shared album.

But Git won’t let you add your photos unless you first answer a simple question:

“Do you know what changed here while you were gone?”

That’s what git pull really is.

Not a command.
Not a network operation.

It’s Git asking you to look at the latest version of the story before continuing your own.

Pulling means:

• First, bring their new photos into your album

• Then, figure out how your photos fit into this updated story

And this is where timelines collide.

Git Doesn’t Decide. You Do.

At this point, Git doesn’t decide anything for you.

It simply asks:

“How do you want these stories combined?”

We briefly touched on this earlier in Part 2, and if merge vs rebase still feels fuzzy, this is a good moment to pause and read that part first.
Everything here builds on that idea.

But now, let’s look at them in context.

Merge: Keep the Story Honest

Merging is Git saying:

“Both stories happened. Let’s keep them exactly as they were.”

You keep:

• Your photos

• Their photos

• And a clear marker showing where the stories met

The album might look a little messy, but it’s honest.

Nothing is rewritten.
Nothing is hidden.

This is why merges are safe for shared timelines; they respect history.

Rebase: When You’re Allowed to Rewrite History

Rebasing is more subtle.

It’s Git saying:

“What if your story had started after you saw their photos?”

Your photos don’t disappear.
But they’re replayed; one by one, on top of the updated album.

The result:

• A cleaner, linear story

• Fewer “meeting points”

• Less noise in the album

This works beautifully as long as your story was private, a branch no one else pulled from.

Rewriting shared history, however, is like changing photos someone else already framed.

That’s not a technical problem, it’s a social one.

When Git Stops and Asks You to Choose

Sometimes, Git can't automatically combine changes.

Maybe you both edited the same line of code differently.
Maybe you both renamed the same function.

When this happens, Git marks the conflict directly in your file:

<<<<<<< HEAD
Your version of the code
=======
Their version of the code
>>>>>>> branch-name

Git isn't being cryptic, it’s very literal.

It's just showing you both stories and asking:

"Which one do you want? Or can you write something better?"

You:

1. Look at both versions

2. Decide which to keep (or combine them)

3. Remove the markers (<<<<<<<, =======, >>>>>>>)

4. Tell Git: "This is how I'm combining them"

That's it. That's conflict resolution.

Not scary. Just a choice.

Everyone Breaks Something Eventually

Sooner or later, everyone does this:

• Commits something they didn’t mean to

• Pulls in the wrong direction

• Rebases when they shouldn’t

• Or just… panics

This is where people assume Git is unforgiving.

It’s not.

Reset: “I Didn’t Mean That”

Reset is not destruction.

It’s saying:

“I want to return to an earlier version of the album.”

Sometimes you want to:

• Go back, but keep the photos aside [SOFT reset]

• Or go back and pretend those photos never existed [HARD reset]

Different resets reflect different intentions, not different skill levels.

Git doesn’t judge why you’re going back.
It just does what you ask.

Reflog: The Safety Net Nobody Told You About

Here’s the part most people don’t know and probably should.

Git keeps a private log of:

• Where you’ve been

• What HEAD pointed to

• Even the mistakes you “undid”

This is called the reflog.

Think of it as Git’s black box recorder.

Even if you:

• Reset too hard

• Rebased incorrectly

• Lost a commit you swear existed

Git quietly says:

“Relax. I remember.”

And that’s why most Git mistakes are recoverable, Panic just hides the path back.

Git is not magic. It’s careful.

At no point did Git make a decision for you.

It didn’t choose:

• How stories merge

• Which history matters

• Or what should be forgotten

Git only records what happened
and asks how you want to move forward.

Divergent timelines aren’t failures.
They’re proof that real work happened.

And once you stop fearing them, Git stops feeling magical, and starts feeling reliable.

You’re Not Scared Anymore

This feels like a good place to stop.

Not because there's nothing left to learn; workflows, pull requests, team strategies, but because you now have the mental model to figure those out yourself.

You understand what Git is.
You're not scared anymore.

The rest is just practice.

(And if I ever write Part 5, it'll be because you asked for it. Until then, your timelines are in your hands.)