Branch Naming Conventions

Clear branch names help teams:
• Instantly understand the purpose of a branch
• Reduce confusion during code reviews
• Avoid accidental merges into wrong branches
• Integrate smoothly with CI/CD and issue trackers
Poor naming like test123 or new-branch creates long-term maintenance issues.

Most teams organize branches by purpose.

Main Branches

These represent stable or long-lived code:
• main / master → production-ready code
• develop → integration branch for upcoming releases
These branches should remain clean and protected.

Used for new features or enhancements.

Format:
Examples:
Best practices:
• Use lowercase
• Use hyphens instead of spaces
• Keep names short but meaningful

Used to fix bugs in existing functionality.

Format:
Examples:
For urgent production issues, some teams prefer:

Used when preparing a versioned release.

Format:
Examples:
Release branches allow:
• Final bug fixes
• Version bumps
• Release-specific testing

Used for non-feature tasks.

Format:
Examples:
Useful for:
• Dependency upgrades
• Code refactoring
• Build system changes

When using tools like Jira, GitHub Issues, or Linear:

Format:
Benefits:
• Direct traceability
• Automated linking in PRs
• Easier auditing

General rules that scale well:
• Use lowercase
• Use hyphens (-) instead of underscores
• Avoid vague names (test, temo, new)
• Keep it readable and searchable
• Be consistent across the team

A simple and effective standard:
Example:

• Branch naming improves clarity, collaboration, and automation.
• Use prefixes like feature/, bugfix/, hotfix/, release/, and chore/.
• Keep names lowercase, short, and descriptive.
• Include issue IDs for traceability when possible.
• Consistency matters more than perfection—agree on a team standard.