Branches: Work Without Fear

The problem branches solve

You are building a website that people use. You want to add a new contact page. It will take three days, and half-finished code will break things in the meantime. Meanwhile, a visitor reports a typo that needs fixing today.

If everything is on one line of work, you are stuck. You cannot publish the typo fix without publishing your half-built contact page.

A branch solves this. It is a separate line of work that starts from where you are now. You do the risky, unfinished work on your own branch, while the main branch stays stable and ready to publish. When your branch is finished and tested, you merge it back in.

What a branch really is

Here is the secret, and it makes everything easier: a branch is just a label that points to a commit. Making a branch is instant and costs nothing, because Git does not copy your files. It only creates a new label.

main:      A --- B --- C
                        \
feature:                 D --- E

main still points at C. The feature branch started at C and has two more commits, D and E. Work on feature does not touch main.

The default branch is called main. (Older projects call it master.) A special pointer called HEAD says which branch you are on right now, and new commits are added to that branch.

The commands

(You will also see git checkout, the older command that does the same jobs. switch is clearer.)

Try it: your first branch

The project below is a small website with one commit. Follow along in the terminal:

1. git branch shows only main.
2. git switch -c feature/contact-page creates the branch and moves you onto it.
3. Click New file (type contact.html, press Add), write something in it, and save.
4. git add contact.html and git commit -m "Add contact page".
5. git log --oneline: your new commit is on top, and HEAD -> feature/contact-page shows where you are.
6. git switch main. Look at the file list: contact.html has disappeared! It is safe on your feature branch, but it is not part of main.
7. git switch feature/contact-page and the file comes back.

That moment is the whole idea: switching branches changes the files in your folder to match.

Merging: bringing work back

When the contact page is done, you merge it into main. You switch to the branch that receives the work, and merge the other one in:

git switch main
git merge feature/contact-page

Git can merge in two ways:

• Fast-forward. If main has not moved since you branched, Git simply moves the main label forward to your latest commit. No new commit is needed. You will see Fast-forward.
• Merge commit. If both branches have new commits, Git combines the two and makes a special merge commit with two parents. Git handles it automatically when the changes are in different places. When the same lines changed on both sides, you get a conflict, the subject of the next lesson.

After merging, delete the finished branch. The commits are safe in main:

git branch -d feature/contact-page

Naming branches

Good branch names say what the work is. Teams often use a prefix:

Use lowercase and hyphens, and no spaces.

A branching workflow that works

1. Start from an up-to-date main.
2. git switch -c feature/something.
3. Make small commits, with good messages.
4. When done and tested, merge into main (on a team, through a pull request, which is lesson 8).
5. Delete the branch.
6. Repeat.

This keeps main always working, which is a rule professional teams care about. main should always be in a state you could publish.

Switching with unfinished work

Git will not let you switch branches if your uncommitted changes would be overwritten:

error: Your local changes to the following files would be overwritten by checkout

You have three choices: commit your work, stash it (lesson 4), or discard it with git restore. Never ignore the message.

Try it

Do the full branch cycle: create a branch, commit on it, merge it back and delete it.

Now keep two pieces of work apart. Create two feature branches, each with its own commit, and finish on main without merging either.