Branching without fear

A branch is just a movable pointer to a commit — creating one doesn't duplicate your files, it just adds a new label you can move independently. That's why Git branching is fast and cheap, and why there's rarely a good reason to be afraid of making one.

Creating and switching branches

git branch feature-x        # create a branch (doesn't switch to it)
git switch feature-x        # switch to it
# or, in one step:
git switch -c feature-x

(You'll also see git checkout -b feature-x in older tutorials and codebases — same effect as git switch -c; switch is the newer, less overloaded command for this specifically.)

Once you're on feature-x, commits you make move that branch's pointer forward — main (or whatever branch you started from) doesn't move and isn't affected until you merge.

Merging

git switch main
git merge feature-x

This brings feature-x's commits into main. If main hasn't moved since you branched, this is a "fast-forward" — Git just moves main's pointer up to match feature-x, no new commit needed. If both branches have new commits, Git creates a merge commit — a snapshot with two parents, which is how the two histories get reconciled into one. (Sometimes that reconciliation has conflicts — the next-but-one lesson covers exactly that.)

Why branch at all

The real value isn't the command, it's the workflow it enables: keep main always in a working state, and do risky/in-progress work on a branch where breaking things doesn't affect anyone else — including future-you, coming back to main for something unrelated.

The checkpoint for this lesson

In your practice repository, create a branch, make two or three commits on it, switch back to main, and merge it in. Run git log --oneline --graph --all afterward — that flag combination draws your branch history as an actual graph in the terminal, which is worth seeing at least once.