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

Source: Dev.to

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?

In Git, this “you are here” marker is called HEAD. HEAD is just a pointer. It points to whichever commit you’re currently looking at—most of the time, the latest commit (the present moment in your project’s timeline).

commit 0   # moves HEAD to wherever you tell it to go.

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 follows it. Keep this in mind as we discuss branches next.

Branches: Multiple Timelines

What if, while making your 3‑layered cake, you suddenly think, “What if I made a chocolate version too?” You don’t want to mess up the original vanilla cake, but you want to try the new idea.

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, then evolve differently. This is what branches are.

A branch is just a label that points to a commit. Creating a new branch creates 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, experiment freely—while main stays untouched. Your original vanilla cake is safe.

Merging: Bringing Timelines Together

After experimenting, you realize the chocolate version turned out amazing and you want to bring those changes back into the main cake recipe. This is called merging.

When you merge, you tell 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. Most of the time Git can combine the changes automatically, but sometimes merge conflicts arise when both timelines modified the same part of the same file differently. In that case you must resolve the conflict manually, then complete the merge.

Rebasing: Rewriting History

If you don’t want a messy merge commit and prefer a clean linear history, you can use rebase.

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)

Commit 4 becomes a new commit 4′ with the same changes but a different parent. You’ve rewritten history, making it linear and tidy.

Golden rule: Never rebase commits that you’ve already shared with others. Rewriting shared history creates a mess for collaborators.

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

You’ve Got the Power Now

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

So far, all of this has been happening on your machine—your personal “photo album.”

What happens when you want to share these albums with your team? How do you keep everyone’s timelines in sync? That’s the focus of Part 3.