Branches

Many people think a branch is a copy of the code. That's not true.

A branch is just a pointer. It's a small file that contains the hash of a commit. Creating a branch is instant. It takes almost no disk space.

Imagine you're working on a website. The site works well. Now you want to add a new page.

If you work directly on main, you risk breaking the site. Your changes in progress might not be finished.

With a branch, you work separately. The site stays functional on main. When your new page is ready, you bring it back into main.

* main
  feature/header

# Creates a new branch called feature/about
# Note: you stay on the current branch

The new branch shows up in the list, but the star hasn't moved: you are still on main.

  feature/about
  feature/header
* main

# Switches to the feature/about branch
# Files change to match this branch

# Creates a new branch AND switches to it
# This is a shortcut for: git branch + git switch

The -c option means "create". It's the most commonly used shortcut. You create and switch in a single command.

When in doubt, git status always tells you which branch you are on:

On branch feature/footer
nothing to commit, working tree clean

To merge, you must first be on the branch that will receive the changes. Usually, that's main.

Updating a1b2c3d..e4f5g6h
Fast-forward
 about.html | 24 ++++++++++++
 1 file changed, 24 insertions(+)

The commits from feature/about are now part of main. The branch itself still exists: you can delete it or keep working on it.

Git can merge in two different ways. It depends on what happened on the branches.

Case 1: Fast-forward This happens when main hasn't moved since the branch was created. Git simply moves the pointer forward. No need to create a new commit.

You can recognize this case in Git's output: it says "Fast-forward".

Updating a1b2c3d..d4e5f6g
Fast-forward
 index.html | 8 ++++
 1 file changed, 8 insertions(+)

Case 2: Merge commit This happens when both branches have different commits. Git creates a new commit that combines the two. This commit has two parents.

Here Git's output looks different: it names the strategy used to combine the two histories.

Merge made by the 'ort' strategy.
 index.html | 12 ++++++
 1 file changed, 12 insertions(+)

There's a very useful command to see all branches and commits. It draws a graph in the terminal.

*   f7a8b9c (HEAD → main) Merge branch 'feature'
|\
| * d4e5f6a (feature) Add feature
|/
* a1b2c3d Initial commit

This command shows:

• ●Commits (each line with a *)
• ●Branches (names in parentheses)
• ●Links between commits (the lines |, / and \)
• ●Where you are (HEAD →)

A branch name should explain what you're doing on it. Here are the most common conventions:

• ●feature/name — to add a feature. Example: feature/contact-page
• ●fix/name — to fix a bug. Example: fix/mobile-menu
• ●chore/name — for technical maintenance. Example: chore/update-dependencies

Switched to a new branch 'fix/mobile-menu'

Branches quickly become second nature. Until then, here are the traps that come up most often:

• ●Forgetting to go back to main before merging. You must always be on the branch that receives the changes.
• ●Creating a branch from another branch instead of main. Always check where you are with git status before creating a branch.
• ●Working directly on main. Always create a branch, even for a small change. It's safer.
• ●Thinking a branch is a copy of the code. It's just a pointer. Creating 100 branches takes almost no space.

Want to dig deeper? These resources build on this chapter:

• ●git checkout: the old command for switching branches
• ●git log: exploring the history in detail
• ●Resolving a Git merge conflict

Before the exercises, make sure you understood branches. Pick the answer that looks right.