Why Git Branches Switch Instantly: Understanding Branches as Pointers

What a Git branch really is

Git does not store a separate copy of the project for each branch. A branch is simply a pointer (a reference) to a specific commit in the commit graph.

Commits are the core objects

Each git commit creates a new commit object that records the snapshot of the files, the author, the timestamp, the commit message, and a pointer to its parent commit. The series of commits forms a linked list (or a directed acyclic graph when merges occur).

Branches are just labels on commits

Creating a branch with git branch dev adds a new reference named dev that points to the current commit (e.g., C). No files are copied; only the reference is added.

Switching branches with git checkout dev moves the special HEAD pointer from the current branch (e.g., main) to dev. Git then restores the working tree to the snapshot recorded by the commit that dev points to, which is why the switch appears to happen in a fraction of a second.

Why switching is fast

The operation consists of two cheap steps:

Move HEAD to the target branch reference.

Check out the file snapshot of the commit that the branch points to.

Git never copies the whole project or rebuilds it, unlike many older version‑control systems.

Merge explained

When you run git merge dev, Git attempts to combine the changes from the two branch histories. If the histories diverge, Git creates a new merge commit (e.g., G) that has two parents: the tip of dev (commit E) and the tip of main (commit F). The merge commit records that the two branches have been integrated.

Why merge conflicts happen

A conflict occurs when the same line of a file has been changed differently in the two branches. Git cannot decide which change is correct, so it stops and asks the developer to resolve the conflict manually.

Rebase – rewriting history

Rebase works by taking the commits from the current branch (e.g., D and E) and replaying them on top of the latest commit of the target branch ( C). New commits ( D' and E') are created, so the original commits are replaced. This produces a linear history, which is cleaner in git log, but it rewrites history and can confuse collaborators if used on shared branches.

Because of this risk, many teams forbid rebasing public branches.

Why branches are "almost zero cost"

Since a branch only stores a pointer and a commit reference, you can create as many branches as you like (feature branches, hotfixes, refactors) without noticeable performance impact. This encourages experimentation and parallel development.

Key takeaways

Git branches are pointers to commits, not full copies of the code. HEAD indicates the current position in the commit graph.

Merge combines two histories by creating a merge commit.

Rebase rewrites history to produce a linear sequence of commits.

Quick experiment

Initialize a repository, create two branches, make a few commits on each, then run git merge and view the graph with git log --graph --oneline. You will see the commit structure and how Git represents branches and merges.