How do branches work in Git?

Question

Accepted Answer

**Branches** in Git let you diverge from the main line of development to work on something in **isolation** — without affecting the main code. They're lightweight and central to Git workflows, enabling parallel work and safe experimentation.

## What a branch is

```text
A branch is a MOVABLE POINTER to a commit. The default is usually "main".
  → creating a branch = creating a new pointer (cheap/instant — not a copy of files)
  → commits on a branch advance that branch's pointer
  → branches let you work on different things in parallel, isolated from each other
```

Branches are **lightweight** (just pointers to commits, not copies) — so creating and switching branches is fast and cheap, which is why Git branching is used heavily.

## Working with branches

```bash
git branch                     # list branches (* marks the current one)
git branch feature-x           # create a branch
git checkout feature-x         # switch to it
git switch feature-x           # switch (newer command)
git checkout -b feature-x      # create AND switch (shortcut)
git switch -c feature-x        # create and switch (newer)

git branch -d feature-x        # delete a branch (after merging)
```

## The branching workflow (feature branches)

```bash
# the common pattern: a branch per feature/fix
git switch -c feature/login    # branch off main for a new feature
# ... make commits on the branch (isolated from main) ...
git switch main                # back to main
git merge feature/login        # merge the completed feature into main
# → main stays stable; work happens on branches; merge when ready
```

The common workflow: create a **feature branch** for each piece of work, develop it in isolation, then **merge** it back — keeping the main branch stable while work proceeds in parallel.

## Why it matters

Understanding branches is essential because they're central to virtually all Git workflows, so grasping them is fundamental to collaborative development.

Branches enable **isolation** — diverging from the main code to work on a feature, fix, or experiment **without affecting the main line** until ready — which is foundational to how teams work: multiple people (or one person on multiple tasks) can work in **parallel** on separate branches, keeping the main branch stable while development proceeds.

Understanding that branches are **lightweight movable pointers** (not copies of files, just pointers to commits) explains why Git branching is so fast, cheap, and heavily used — a key reason Git's branching model is praised.

Knowing how to **create, switch, list, and delete** branches (with both the classic `checkout` and newer `switch` commands) is everyday practical knowledge.

Most importantly, understanding the **feature-branch workflow** (creating a branch per feature/fix, developing in isolation, then merging back) is fundamental because it's the standard pattern in nearly all professional development — keeping main stable, enabling parallel work, supporting code review (via pull requests on branches), and isolating changes.

Since branches are central to all Git workflows (collaboration, feature development, code review, releases) and the feature-branch pattern is near-universal in professional development, understanding how branches work — what they are, their lightweight nature, the commands, and the feature-branch workflow — is essential, frequently-applied Git knowledge, a core concept that underpins how teams develop software collaboratively and a fundamental skill for any developer working with Git.