Choose a useful Git branch naming convention

A practical convention is type/short-description, optionally including an issue identifier. Names such as feature/123-user-login and hotfix/payment-timeout communicate purpose without requiring someone to open the branch first. The exact prefixes are a team agreement, not a Git standard.

Common prefixes

Use the categories your workflow actually needs. A prefix does not grant permissions, trigger a deployment, or link an issue unless your automation is configured to interpret it.

Keep names readable and portable

Lowercase words and hyphen-separated descriptions reduce ambiguity. If your issue tracker uses uppercase identifiers, a convention such as feature/PROJ-123-oauth-login can retain that identifier deliberately; do not simultaneously claim that every character must be lowercase.

Git forbids spaces and several special forms, including .., @{, and ref components ending in .lock. Underscores, many periods, and non-ASCII characters are not all forbidden by Git, though a team may restrict them for portability and tooling. Validate the actual syntax with:

git check-ref-format --branch feature/123-user-login

This checks Git's rules, not your naming policy. A valid name can still conflict with an existing ref namespace: a branch named feature can prevent creating feature/login. Avoid case-only differences as well, because filesystems and tools handle them inconsistently.

Fit the workflow

Git Flow commonly uses long-lived main and develop branches with feature, release, and hotfix branches. GitHub Flow emphasizes a deployable main branch and short-lived branches reviewed through pull requests. These models do not require every team to adopt the same prefix vocabulary or branch lifetime.

Keep experimental branches recognizable and clean them up according to an agreed retention policy. A wip/ name signals intent to people; it is not a backup or access-control mechanism.

Rename and enforce deliberately

git branch -m old-name new-name renames locally. Publishing a replacement remote name and removing the old one requires coordination, or use a hosting service's rename workflow with its documented behavior.

A server-side rule or hook can reject disallowed names where supported. A CI check runs after a ref has been created and can gate merging or deployment, but does not by itself prevent branch creation. Apply the policy consistently, including exceptions for release automation, and document a few concrete examples instead of relying on an unexplained regular expression.

See Git ref-name validation, git-branch, and GitHub Flow.