What a branch is (pointer to a commit) in Git - Deep Dive

Overview - What a branch is (pointer to a commit)

What is it?

A branch in Git is like a label or pointer that marks a specific commit in the history of your project. It helps you keep track of different lines of work or features separately. When you create a branch, you are creating a new pointer that can move independently as you add new commits. This allows multiple versions of your project to exist side by side.

Why it matters

Branches let you work on new features or fixes without disturbing the main project. Without branches, all changes would mix together, making it hard to manage or undo mistakes. Branches make teamwork easier and safer by isolating changes until they are ready to be combined.

Where it fits

Before learning about branches, you should understand basic Git concepts like commits and the repository structure. After mastering branches, you can learn about merging, rebasing, and advanced workflows like pull requests and continuous integration.

Mental Model

Core Idea

A branch is simply a movable pointer that marks a specific commit in your project's history.

Think of it like...

Imagine a bookmark in a book that points to a particular page. You can move the bookmark forward as you read more pages, or have multiple bookmarks to keep track of different chapters you are reading separately.

Repository history:

Commit1 --- Commit2 --- Commit3 --- Commit4
                  ↑
                branch 'main'

When you create a new branch 'feature':

Commit1 --- Commit2 --- Commit3 --- Commit4
                  ↑             ↑
                main          feature

Each branch points to a commit and moves forward as new commits are added.

Build-Up - 7 Steps

1

Foundation

Understanding commits as snapshots

Concept: Commits are snapshots of your project at a point in time.

In Git, every change you save is called a commit. Think of it as a photo of your project files at that moment. Each commit has a unique ID and points to its parent commit, forming a chain.

Result

You have a chain of commits representing your project's history.

Understanding commits as snapshots helps you see how Git tracks changes over time.

2

Foundation

What is a pointer in Git?

Concept: Pointers are names that refer to specific commits.

Git uses pointers to mark commits. The most common pointer is HEAD, which shows your current working commit. Branches are also pointers that move as you add commits.

Result

You know that pointers are labels that help Git remember where you are in the commit history.

Knowing that branches are pointers clarifies that they don't hold code themselves but just mark commits.

3

Intermediate

Creating and moving branches

🤔Before reading on: do you think creating a branch copies files or just creates a pointer? Commit to your answer.

Concept: Branches are lightweight pointers that move forward with new commits.

When you create a branch, Git makes a new pointer to the current commit. As you commit changes on that branch, the pointer moves forward to the new commits. No files are copied; only the pointer changes.

Result

You can have multiple branches pointing to different commits, each moving independently.

Understanding branches as moving pointers explains why creating branches is fast and uses little space.

4

Intermediate

Switching branches changes HEAD

🤔Before reading on: does switching branches change your files immediately or only after a commit? Commit to your answer.

Concept: HEAD is a special pointer that shows which branch and commit you are working on.

When you switch branches, Git moves HEAD to point to that branch. Git then updates your working files to match the commit the branch points to. This lets you work on different versions easily.

Result

Your working files reflect the branch you have checked out.

Knowing that HEAD moves with branch switches helps you understand how Git manages your workspace.

5

Intermediate

Branches enable parallel work

Concept: Branches let multiple lines of work happen without interfering.

By creating separate branches, you can develop features or fixes independently. This isolation prevents accidental changes to the main code until you are ready to merge.

Result

Teams can collaborate safely and efficiently using branches.

Recognizing branches as isolated pointers explains why they are essential for teamwork.

6

Advanced

Branch pointers stored as files

🤔Before reading on: do you think branch pointers are stored inside commits or separately? Commit to your answer.

Concept: Branches are stored as simple files containing commit IDs inside the .git folder.

Inside the .git directory, each branch is a file that holds the commit hash it points to. When you commit, Git updates this file to the new commit hash. This simple design makes branches fast and lightweight.

Result

Branches are just text files pointing to commits, not complex objects.

Knowing the storage mechanism reveals why branches are cheap and easy to manage.

7

Expert

Detached HEAD and branch pointers

🤔Before reading on: if HEAD points directly to a commit, is that a branch or something else? Commit to your answer.

Concept: HEAD can point directly to a commit, not just a branch, causing a 'detached HEAD' state.

Normally, HEAD points to a branch pointer. But you can make HEAD point directly to a commit hash. This means you are not on any branch. Commits made here are 'orphaned' unless you create a branch to save them.

Result

Detached HEAD lets you explore history but can cause lost commits if not careful.

Understanding detached HEAD clarifies a common source of confusion and lost work in Git.

Under the Hood

Git stores commits as objects identified by hashes. Branches are simple files inside the .git/refs/heads directory that contain the hash of the commit they point to. When you commit, Git creates a new commit object and updates the branch file to point to this new commit. HEAD is a special pointer stored in .git/HEAD that usually contains the name of the current branch. When switching branches, Git updates HEAD to point to the new branch and updates the working directory to match the commit the branch points to.

Why designed this way?

Git was designed for speed and efficiency. Using simple text files as pointers avoids complex data structures and makes branch operations very fast. This design also makes branching cheap in terms of storage and performance, encouraging developers to create many branches. Alternatives like copying files or duplicating history would be slow and wasteful.

┌─────────────┐
│  .git/HEAD  │
│  ref: refs/heads/main  │
└─────┬───────┘
      │ points to
┌─────▼─────────────┐
│ .git/refs/heads/  │
│       main        │
│  commit_hash_abc  │
└────────┬──────────┘
         │ points to
┌────────▼──────────┐
│    Commit Object  │
│  hash: abc123def  │
│  parent: xyz789   │
└───────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does creating a branch copy your project files? Commit yes or no before reading on.

Common Belief: Creating a branch copies all project files to a new location.

Reality: Creating a branch only creates a new pointer to a commit; no files are copied.

Why it matters: Believing branches copy files leads to confusion about performance and storage, and may cause unnecessary fear of creating branches.

Quick: Does switching branches keep your current changes in place? Commit yes or no before reading on.

Common Belief: Switching branches keeps your current uncommitted changes exactly as they are.

Reality: Switching branches updates your working files to match the target branch's commit, which can overwrite uncommitted changes unless stashed or committed.

Why it matters: Not understanding this can cause accidental loss of work when switching branches.

Quick: Is HEAD always pointing to a branch? Commit yes or no before reading on.

Common Belief: HEAD always points to a branch name.

Reality: HEAD can point directly to a commit hash, causing a detached HEAD state.

Why it matters: Ignoring detached HEAD can cause confusion and lost commits if new work is made without creating a branch.

Quick: Does deleting a branch delete the commits it pointed to? Commit yes or no before reading on.

Common Belief: Deleting a branch deletes all commits that were on that branch.

Reality: Deleting a branch only removes the pointer; commits remain if reachable from other branches or tags.

Why it matters: Misunderstanding this can cause unnecessary fear of deleting branches or confusion about commit history.

Expert Zone

1

Branches are just pointers, but the real power comes from how Git manages commit graphs and references behind the scenes.

2

The lightweight nature of branches encourages frequent branching and merging, which is a core part of modern Git workflows.

3

Detached HEAD states are useful for exploring history or testing, but require care to avoid losing commits.

When NOT to use

Branches are not suitable for representing long-term stable releases; tags or release branches are better. Also, for very large monorepos, specialized branching strategies or tools may be needed to manage complexity.

Production Patterns

In professional teams, feature branches are created for each new task and merged back into main branches via pull requests. Branch naming conventions and protected branches help maintain code quality and history integrity.

Connections

Pointers in Computer Science

Branches in Git are a specific example of pointers used in programming and data structures.

Understanding general pointers helps grasp how branches simply mark locations in commit history without copying data.

Version Control Systems

Branches are a fundamental concept in many version control systems, not just Git.

Knowing how branches work in Git helps understand branching in other systems like Mercurial or SVN, despite implementation differences.

Bookmarks in Books

Branches function like bookmarks that mark your place in a book's pages.

This connection helps visualize how branches mark commits and move forward as you add new commits.

Common Pitfalls

#1 Losing work by switching branches with uncommitted changes.

Wrong approach:

git checkout feature
# without committing or stashing changes on main branch

Correct approach:

git stash
git checkout feature
git stash pop

Root cause:

Not understanding that switching branches changes working files and can overwrite uncommitted changes.

#2 Creating many branches but never deleting old ones.

Wrong approach:

git branch feature1
git branch feature2
git branch feature3
# never delete old branches

Correct approach:

git branch -d feature1
git branch -d feature2
# clean up branches after merging

Root cause:

Not realizing that unused branches clutter the repository and make history harder to read.

#3 Committing in detached HEAD state and losing commits.

Wrong approach:

git checkout abc123def
# make commits here without creating a branch

Correct approach:

git checkout abc123def
git checkout -b new-branch
# now commits are saved on new-branch

Root cause:

Not knowing that commits made in detached HEAD are not saved to any branch pointer.

Key Takeaways

A branch in Git is a simple pointer to a commit, not a copy of files.

Branches move forward as you add commits, allowing parallel work streams.

HEAD is a special pointer that shows your current branch and commit.

Switching branches updates your working files to match the branch's commit.

Understanding branches as pointers explains their speed, efficiency, and role in collaboration.