How to create and name branches for pull requests

Branch Naming Matters

Your branch name is visible in the PR, in the git log, and in CI notifications. A descriptive name signals professionalism before anyone reads your code.

Standard Naming Patterns

Most projects follow a type/description pattern:

fix/issue-456-login-timeout
feat/add-csv-export
docs/update-contributing-guide
chore/upgrade-eslint-v9
test/add-unit-tests-for-parser

Check CONTRIBUTING.md -- some projects enforce specific prefixes and reject PRs that do not match. Never work directly on main or master. Always branch.

Creating a Branch

# Always start from a synced main
git checkout main
git pull upstream main

# Create and switch to your branch
git checkout -b fix/issue-123-null-check

# Push branch to your fork
git push -u origin fix/issue-123-null-check

Branch Hygiene

Delete branches after your PR merges. Stale branches clutter your fork and confuse you when you return months later.

# Delete local branch
git branch -d fix/issue-123-null-check

# Delete remote branch
git push origin --delete fix/issue-123-null-check

One issue, one branch. If you find another bug while working, open a separate issue and a separate branch.

Working With Stacked Branches

When one feature depends on another still in review, you can stack branches: branch B off branch A. If A gets merged and you need to rebase B onto main, use git rebase --onto main branch-a branch-b. This replays only the commits unique to B. Stacked branches are an advanced pattern -- use them intentionally, not by accident. For most contributions, a single branch per issue is the clearest approach and what maintainers prefer.