Git Branch: A Lightweight Pointer, Not a Full Copy

Why it exists

In many older version control systems (VCS), creating a branch was a heavy operation, often requiring a full copy of the project's source code. This was slow and discouraged frequent branching. Git was designed to solve this by making branching an incredibly lightweight, core part of the daily workflow.

The mental model

A Git branch is not a separate folder or a copy of your project. It's simply a movable pointer to a specific commit. The default branch is often called main or master. When you create a new branch, you're just creating a new pointer to the same commit you're currently on. As you make new commits on this new branch, only its pointer moves forward, leaving the original branch pointer untouched.

How it works

Git stores its history as a series of snapshots called 'commit objects.' Each commit object points to its parent commit(s), forming a chain of history. A branch is just a named reference that points to the tip of a line of development (the latest commit in that chain). When you switch branches, Git updates a special pointer called HEAD to point to the new branch's tip, and then updates your working directory to match the snapshot of that commit. This process is fast because Git isn't creating copies of files, just moving pointers.

When to use it

Use branches constantly. Create a new branch for every distinct piece of work: a new feature, a bug fix, an experimental idea, or a refactor. This isolates your changes, preventing you from destabilizing the main codebase. It also allows multiple developers to work on different things in parallel without interfering with each other.

When not to use it

There's almost never a reason not to use a branch for new work. The main anti-pattern is committing unstable work directly to the main or master branch in a collaborative project. This branch should be reserved for stable, tested code that has been reviewed and merged from other feature branches. Committing directly to main can block the entire team.

One canonical example

You're tasked with adding a login page. Instead of coding on the main branch, you run git checkout -b feature/login. This creates a new branch called feature/login and switches to it. You make several commits. Meanwhile, a teammate fixes a critical bug on a separate hotfix/bug-123 branch. Your work is completely isolated from theirs. Once your feature is done, you merge it back into main.