Branch Naming Conventions and Strategies

A branch name is not just a label — it is communication. When you look at a list of ten branches in a repository, well-named branches tell you immediately what each one is for. Poorly named branches tell you nothing.

You control your branch names. Adopting a few simple conventions now will make your repositories readable and professional.

The anatomy of a good branch name

Most teams use a prefix/description pattern:

feature/mobile-nav-toggle
fix/contact-form-double-submit
docs/update-readme
refactor/extract-tour-card-component

Prefix: Categorizes the branch by type of work. Common prefixes:

Prefix	When to use it
feature/	New functionality being added
fix/	Bug fix
docs/	Documentation only changes
refactor/	Code restructuring without changing behavior
chore/	Maintenance tasks (dependency updates, config changes)
test/	Adding or fixing tests

Description: Short, lowercase, hyphenated. Specific enough that someone reading it knows what the branch does without opening it.

What to avoid in branch names

• Single words: fix, update, changes — tells you nothing
• Dates as the only identifier: may-27 — tells you when, not what
• Your name as the only identifier: brandon — tells you who, not what
• Spaces or special characters: Git names must be valid path segments. Use hyphens, not spaces. Avoid @, #, *, .., or leading/trailing hyphens.
• Long, verbose names: feature/add-the-pine-ridge-tour-description-and-all-associated-metadata — keep it under 40 characters

Branch strategies for solo development

As a solo developer, the simplest workflow is:

• main — always working, always deployable
• Short-lived feature and fix branches — create, work, merge, delete

Every piece of work gets its own branch. This may feel like overhead on a solo project, but it keeps main clean and gives you a safe place to experiment without breaking what works.

A session might look like:

git switch -c fix/tour-card-image-overflow
# make the fix
git add tours.html styles.css
git commit -m "Fix tour card image overflowing on mobile"
git switch main
git merge fix/tour-card-image-overflow
git branch -d fix/tour-card-image-overflow

Done. main has the fix. The branch is cleaned up.

GitHub Flow: the most common team strategy

For teams, GitHub Flow is the dominant strategy:

1. main is always deployable
2. Every change happens on a branch
3. Branches are short-lived — days, not weeks
4. When work is ready, open a pull request to main
5. After review and approval, merge and deploy

Module 06 covers pull requests in detail. The naming conventions here apply directly to that workflow — every PR comes from a named branch.

Git Flow: a heavier alternative

Some teams use Git Flow, which adds additional permanent branches:

• main — production code
• develop — integration branch where features accumulate before release
• release/ branches — preparing a release
• hotfix/ branches — emergency fixes to production

Git Flow is thorough but adds coordination overhead. Most modern teams, especially those with continuous deployment, use GitHub Flow instead.

For this course, GitHub Flow is the model.

Exercise

Think about the work you have done on your STO project:

1. List five to eight changes you made to the STO site across the HTML, CSS, and JavaScript courses (for example, “added the mobile nav toggle” or “styled the tour card grid”).

2. For each one, write a branch name you would have used if you had been working with branches at the time. Use the prefix/description pattern.

3. In your git-practice folder, create two branches using names from your list (do not commit anything to them yet — just create them):

git branch feature/your-feature-name
git branch fix/your-fix-name

4. Run git branch and review the names. Do they communicate what the work was for?

Recap

• Use a prefix/description pattern: feature/, fix/, docs/, refactor/, chore/.
• The description should be lowercase, hyphenated, and specific enough to understand without reading the code.
• Avoid single-word names, date-only names, spaces, and special characters.
• For solo work: create a branch for every change, merge, delete. Keep main deployable.
• GitHub Flow is the standard team strategy: main is always deployable, short-lived feature branches, pull requests to merge.

The next lesson covers deleting merged branches — keeping your repository clean as you accumulate completed work.