Snake_Case Branch Naming Convention

Snake_Case for Git Branches

Snake_case uses lowercase letters with underscores as word separators. While less common than kebab-case for git branches, it is the preferred convention in some teams — particularly those working primarily with Python, Ruby, or Rust, where snake_case is the standard code style.

Format

type/ticket_number_description_in_snake_case

Examples

Input	Snake_Case Branch
Feature: PROJ-123 "Add User Auth"	feature/proj_123_add_user_auth
Bugfix: #456 "Fix Memory Leak"	bugfix/456_fix_memory_leak
Refactor: REF-90 "Extract Service Layer"	refactor/ref_90_extract_service_layer

When to Choose Snake_Case

Snake_case makes sense when your team values consistency between code conventions and branch names. If your Python project uses snake_case for everything — file names, function names, variable names — extending this convention to branch names creates a uniform developer experience.

Trade-offs

Advantages:

• Consistent with Python/Ruby/Rust naming conventions
• Underscores are distinct from hyphens in ticket IDs (PROJ-123 stays intact as proj-123 while words use underscores)
• Some developers find underscores easier to double-click and select in terminals

Disadvantages:

• Underscores can be hidden by link underlines in documentation, Slack, and emails
• Less common in the broader git community, which may confuse contributors from other projects
• Some CI/CD tools expect kebab-case patterns in branch matching rules

Separating Ticket IDs from Descriptions

One practical advantage of snake_case is when ticket IDs contain hyphens (like JIRA keys). Using underscores for word separation makes the ticket ID visually distinct: feature/PROJ-123_add_user_auth clearly separates the ticket PROJ-123 from the description add_user_auth.