Git is Not Magic- Part 2: Where Are You in the Timeline?

Remember that question from Part 1?

"Where exactly are YOU in this timeline?"

Let's answer it.

The Pointer Called HEAD

Now that we know our commits form a linked list pointing backward through time, there's one crucial piece missing: where are we right now?

Think back to our Polaroid album. You've got all these photos laid out, but you need to know which photo represents "now", which step of the cake you're currently working on. Are you still layering cream? Or have you moved on to adding decorations?

In Git, this "you are here" marker is called HEAD.

HEAD is just a pointer. That's it. It points to whichever commit you're currently looking at. Most of the time, it points to your latest commit, the present moment in your project's timeline.

commit 0 <- commit 1 <- commit 2 <- commit 3
                                      ↑
                                     HEAD

When you make a new commit, HEAD moves forward with you:

commit 0 <- commit 1 <- commit 2 <- commit 3 <- commit 4
                                                  ↑
                                                 HEAD

But here's where it gets interesting: HEAD can move backward too.

You can literally tell Git "take me back to commit 2" and suddenly you're looking at your code exactly as it was back then. It's like picking up an old Polaroid from your album and saying "I want to see what the cake looked like at this stage."

This is what git checkout does it moves HEAD to wherever you tell it to go.

Now here's where HEAD becomes really interesting: it doesn't just point to commits. Most of the time, HEAD points to a branch, and the branch points to a commit. When you make a new commit, the branch moves forward, and HEAD moves with it.

Keep this in mind as we talk about branches next.

Branches: Multiple Timelines

Now let's make things spicy.

What if while making your 3-layered cake, you had a sudden idea: "What if I made a chocolate version too?" You don't want to mess up your original vanilla cake, but you want to try this new idea.

So you take a Polaroid of where you are now, and start a separate album for the chocolate version. Both cakes start from the same point, but now they evolve differently.

This is what branches are.

A branch is just a label that points to a commit. That's literally all it is. And when you create a new branch, you're creating a new timeline that splits off from the current one.

                    ← commit 4 (chocolate-version)
                   /
commit 0 <- commit 1 <- commit 2 <- commit 3 (main)

You can work on chocolate-version, make commits, mess things up, experiment freely - and your main branch stays untouched. Your original vanilla cake is safe.

Merging: Bringing Timelines Together

After experimenting, you realize the chocolate version turned out amazing. You want to bring those changes back into your main cake recipe.

This is called merging.

When you merge, you're telling Git: "Take everything that happened in this alternate timeline and combine it with my current timeline."

commit 0 <- commit 1 <- commit 2 <- commit 3 <- commit 5 (merge commit)
                   \                           /
                    ← commit 4 (chocolate-version)

Git creates a special merge commit that has two parents one from each timeline. It's like saying "this point in history came from both paths."

Most of the time, Git is smart enough to figure out how to combine changes automatically. But sometimes there are merge conflicts situations where Git can't decide which change to keep. This happens when both timelines modified the same part of the same file differently.

It's like if in your chocolate timeline you added dark chocolate frosting, but in your main timeline you already added vanilla frosting to the same layer. Git stops and asks: "Which one do you want?"

You have to manually resolve the conflict pick one, combine them, or do something else entirely. Then you tell Git "okay, I've decided" and complete the merge.

Rebasing: Rewriting History

But what if you don't want that messy merge commit? What if you want your timeline to look clean, like the chocolate experiment happened after the main branch, not alongside it?

This is where rebase comes in.

Rebasing is like saying: "Take all my experimental commits, and pretend they started from a different point in time."

Before rebase:
                    ← commit 4 (chocolate-version)
                   /
commit 0 <- commit 1 <- commit 2 <- commit 3 (main)

After rebase:
commit 0 <- commit 1 <- commit 2 <- commit 3 <- commit 4' (chocolate-version)
                                     (main)

Notice commit 4 became commit 4', it's technically a new commit with the same changes but a different starting point. You've rewritten history.

Rebasing makes your history linear and clean. But here's the golden rule: never rebase commits that you've already shared with others [yes a rule to memorize]. Because you're literally changing history, and if someone else was working off the old history, you'll create a mess.

Think of it like this: merging is honest (it shows both timelines happened), rebasing is tidy (it pretends only one timeline happened).

You've Got the Power Now

Let's recap:

HEAD is just a pointer showing where you are. Branches are just labels, letting you create parallel universes for your code. Merging brings timelines together honestly. Rebasing rewrites history to keep things tidy.

You're not just taking Polaroids anymore, you're organizing entire photo albums, creating alternate storylines, and deciding how they come together.

But here's the thing:

So far, this has all been happening on your machine. Your Polaroids. Your albums. Your timelines.

What happens when you want to share these with your team? When you and a teammate both have photo albums of the same project?

How do you keep them in sync?

How does "your timeline" become "our timeline"?

That's Part 3.