How do you create and manage branches on GitHub?

Think of branches like parallel timelines in a science fiction movie. The main branch is the primary timeline where everything is stable and released. When a developer starts working on a new feature, they create a branch, which is like splitting off into an alternate timeline where they can experiment freely without affecting the main story. When their work is complete and tested, they merge their timeline back into the main one through a pull request.

In Git, a branch is simply a pointer to a specific commit, stored as a 40-character SHA reference in a file under .git/refs/heads/. Creating a branch is nearly instantaneous because Git does not copy any files. It just creates a new pointer. The HEAD reference tracks which branch you are currently working on. When you make a new commit, the current branch pointer advances to the new commit while all other branches stay where they are. This lightweight design means you can have hundreds of branches without any performance penalty.

On GitHub specifically, branches exist both locally and on the remote. When you push a local branch with git push -u origin feature/add-payment-retry, GitHub creates the remote branch and you can see it in the repository's branch dropdown. GitHub adds features on top of Git's branching: branch protection rules prevent direct pushes to important branches like main, requiring changes to come through pull requests. The default branch (typically main) is the target for new pull requests and the branch that GitHub displays by default when someone visits the repository. You can also create branches directly from the GitHub web interface by typing a new branch name in the branch selector dropdown, which is useful for quick documentation fixes.

In production, most teams follow GitHub Flow: main is always deployable, developers create short-lived feature branches with descriptive names like feature/42-international-checkout or fix/retry-timeout-payments, push them to GitHub, open a pull request, get code review, and merge. Some organizations use release branches (release/v2.3) for versioned software. The key practice is keeping branches short-lived, typically merging within a few days. Long-lived branches diverge from main and create painful merge conflicts. After merging, branches should be deleted to keep the repository clean, and GitHub offers an automatic branch deletion setting for merged pull requests.

A beginner gotcha is forgetting to pull the latest main before creating a feature branch, which leads to your branch being based on stale code. Always run git pull origin main before branching. Another common mistake is naming branches poorly. Names like 'test' or 'fix' tell you nothing about what the branch contains. Use descriptive, prefixed names that include the issue number when applicable.