Branch Naming Policies

The Hook (The "Byte-Sized" Intro)

fix, test2, johns-branch, final-final-v3. Without naming conventions, your branch list reads like a teenager's folder structure. Good branch names tell you the type, scope, and purpose at a glance. A team with consistent naming can automate CI, filter branches, and understand what everyone is working on — just from the branch name.

📖 What are Branch Naming Policies?

Agreed-upon rules for how branches should be named, enabling consistency, automation, and quick understanding across the team.

Conceptual Clarity

Standard naming pattern:

<type>/<ticket>-<short-description>

Common branch types:

Prefix	Purpose	Example
`feature/`	New functionality	`feature/AUTH-42-login-form`
`fix/` or `bugfix/`	Bug fixes	`fix/AUTH-99-null-check`
`hotfix/`	Urgent production fix	`hotfix/PROD-501-crash`
`chore/`	Maintenance, deps	`chore/deps-update-react`
`docs/`	Documentation only	`docs/api-readme`
`release/`	Release preparation	`release/v2.1.0`
`experiment/`	Spike or prototype	`experiment/new-cache`

Naming rules:

Rule	Good	Bad
Lowercase	`feature/login`	`Feature/Login`
Hyphens for spaces	`add-user-auth`	`add_user_auth`
Include ticket ID	`AUTH-42-login`	`login`
Short but descriptive	`fix/null-check`	`fix/fixing-the-thing`
No special characters	`feature/auth`	`feature/auth@v2`

Real-Life Analogy

Branch names are like file names in a shared drive. When everyone uses 2026-Q1-Report.pdf, you can find anything. When everyone uses stuff.pdf, chaos ensues.

Visual Architecture

flowchart LR BRANCH["Branch Name"] --> TYPE["type/"] TYPE --> TICKET["TICKET-ID"] TICKET --> DESC["-short-description"] style BRANCH fill:#0f3460,stroke:#53d8fb,color:#53d8fb

Why It Matters

Clarity: Anyone can understand a branch's purpose from its name.
Automation: CI can trigger different pipelines based on prefix (e.g., release/ → deploy).
Filtering: git branch --list 'feature/*' finds all feature branches.
Traceability: Ticket IDs link branches to issues and PRs.

Code

bash

# ─── Good branch names ───
git checkout -b feature/AUTH-42-login-form
git checkout -b fix/CORE-99-null-pointer
git checkout -b hotfix/PROD-501-payment-crash
git checkout -b release/v2.1.0

# ─── Filter branches by type ───
git branch --list 'feature/*'
git branch --list 'hotfix/*'

# ─── Enforce naming with a hook ───
cat > .git/hooks/pre-push << 'EOF'
#!/bin/sh
BRANCH=$(git rev-parse --abbrev-ref HEAD)
PATTERN="^(feature|fix|hotfix|chore|docs|release|experiment)/"
if ! echo "$BRANCH" | grep -qE "$PATTERN"; then
  echo "❌ Branch '$BRANCH' doesn't follow naming convention."
  echo "   Use: feature/, fix/, hotfix/, chore/, docs/, release/"
  exit 1
fi
EOF
chmod +x .git/hooks/pre-push

Key Takeaways

Use type/ticket-description format for all branches.
Common types: feature/, fix/, hotfix/, chore/, release/.
Include ticket IDs for traceability.
Enforce naming with pre-push hooks or CI checks.

Interview Prep

Q: Why are branch naming conventions important? A: They provide clarity (anyone understands the branch purpose), enable automation (CI can trigger based on prefix), support filtering (git branch --list 'feature/*'), and ensure traceability (ticket IDs link to issues).
Q: What is a good branch naming convention? A: type/TICKET-ID-short-description using lowercase and hyphens. Types include feature/, fix/, hotfix/, chore/, release/. Example: feature/AUTH-42-login-form.
Q: How do you enforce branch naming? A: A pre-push hook that validates the branch name against a regex pattern. Server-side, platforms like GitHub/GitLab can enforce naming rules via branch protection settings.