Git Branch Name Generator
Convert task descriptions to valid branch names — pick a convention, add a ticket number, and copy
Branch Type
New feature
Spaces, special characters, and uppercase letters are sanitized automatically.
Enter a task description above to generate a branch name.
Your JIRA ticket is “PROJ-1234: Fix user authentication timeout on mobile devices.” You need a branch name like fix/PROJ-1234-fix-user-auth-timeout-mobile — lowercase, no special characters, ticket prefix, under 60 characters. You could type it out and hope you got the convention right, or you could paste the ticket title and get the branch name in the correct format instantly.
Why This Generator (Not the Git Command Generator)
PureDevTools has a Git Command Generator for building git commands visually (checkout, merge, rebase, etc.). This tool is specifically for branch naming — paste a task description, pick your convention (Conventional Commits, GitFlow, GitHub Flow), add a ticket prefix, and get a valid branch name with the correct format. Everything runs in your browser; no data is sent anywhere.
What Is a Git Branch Name Generator?
A git branch name generator converts a plain-language task description into a properly formatted branch name that follows your team’s naming convention. It handles the tedious parts automatically: lowercasing, replacing spaces with hyphens, removing special characters, prepending ticket numbers, and enforcing length limits.
Consistent branch names make repositories easier to navigate, help CI/CD pipelines match branches to tickets, and simplify code review by making a branch’s purpose immediately obvious from its name.
Git Branch Name Rules
Git enforces several hard rules on branch names. A valid branch name:
- Cannot contain spaces — use hyphens (
-) or slashes (/) as separators - Cannot contain
..(two consecutive dots),@{, or\\ - Cannot start with a dot
.or hyphen- - Cannot end with a dot
.or.lock - Cannot contain control characters or the symbols
~ ^ : ? * [ ] - Cannot start or end with
/, and cannot contain// - Cannot be the single character
@
Beyond git’s hard rules, best practices recommend keeping branch names lowercase (avoiding case-sensitivity issues on macOS and Windows), keeping them under 50–100 characters, and following a consistent prefix convention across the team.
Branch Naming Conventions
Conventional Commits Style
The most widely adopted convention maps directly to Conventional Commits commit types:
{type}/{optional-ticket-}{slug}
Supported types:
| Type | Purpose | Example |
|---|---|---|
feat/ | New feature | feat/add-oauth-login |
fix/ | Bug fix | fix/jira-42-fix-login-loop |
hotfix/ | Critical production fix | hotfix/payment-gateway-crash |
refactor/ | Code refactoring | refactor/extract-auth-service |
docs/ | Documentation | docs/update-api-readme |
test/ | Tests | test/add-integration-tests |
chore/ | Build, tooling, deps | chore/upgrade-dependencies |
release/ | Release preparation | release/v3.0.0 |
ci/ | CI/CD pipeline | ci/add-coverage-report |
This convention is the default recommendation for teams already using Conventional Commits for their commit messages, because the branch type vocabulary is identical.
GitFlow
GitFlow uses a different set of prefixes that map to its lifecycle:
{lifecycle-prefix}/{ticket-}{slug}
| Prefix | Purpose | Example |
|---|---|---|
feature/ | New feature development | feature/add-oauth-login |
bugfix/ | Non-critical bug fix | bugfix/fix-login-loop |
hotfix/ | Critical production patch | hotfix/payment-gateway-crash |
release/ | Release branch | release/v3.0.0 |
support/ | Long-term support | support/v2.x-security-updates |
GitFlow works best for products with scheduled releases and multiple long-lived branches (main, develop, release branches).
GitHub Flow
GitHub Flow is a simplified workflow designed for continuous delivery. Branch names use hyphens instead of slashes as separators:
{type}-{ticket-}{slug}
Examples: feat-add-oauth-login, fix-login-loop, refactor-auth-service
GitHub Flow suits teams that ship to production frequently from a single main branch. The flatter naming avoids the hierarchy implied by slashes, which some prefer.
Custom Prefix
For teams with established conventions that don’t fit the presets, the Custom mode lets you define your own prefix. The slug sanitization and ticket-number formatting still apply — only the prefix changes.
Adding Ticket Numbers
Most teams include their issue tracker ticket number in branch names to link the branch directly to a task:
- JIRA:
JIRA-123→ branch usesjira-123-prefix in the slug - GitHub Issues:
#42orGH-42→gh-42-or42- - Linear:
ENG-456→eng-456- - Any tracker: The tool lowercases the ticket ID and appends a hyphen before the description slug
Examples with tickets:
feat/jira-123-add-user-authentication
fix/gh-42-fix-null-pointer-in-cart
hotfix/eng-7-payment-gateway-crash
Including ticket numbers in branch names enables many workflow integrations:
- GitHub auto-links branches to issues
- JIRA can show branch status on ticket cards
- PR titles can be pre-populated from the branch name
git log --onelineimmediately shows what each branch fixed
Configuring Maximum Branch Name Length
The default maximum is 50 characters, which balances readability with compatibility across tools. When a generated name exceeds the limit, the tool truncates the description slug at a word boundary (hyphen) to avoid cutting mid-word.
Recommended limits:
| Environment | Recommended Max |
|---|---|
| General use | 50 characters |
| GitHub, GitLab, Bitbucket | 100 characters (hard limit varies) |
| Azure DevOps | 256 characters |
| Some terminals/tools | 50–60 characters for display comfort |
If you need the ticket number to always appear in full, keep max length at 50+ characters when using longer ticket IDs like JIRA-12345.
Validating Existing Branch Names
The validator checks a branch name against git’s hard rules and common best practices. It reports:
- Errors: violations that would prevent git from accepting the name
- Warnings: conventions that are valid but may cause problems (uppercase letters on case-insensitive filesystems, very long names)
- Detected convention: whether the name matches Conventional, GitFlow, or GitHub Flow patterns
Frequently Asked Questions
Why can’t git branch names have spaces?
Git uses branch names as directory names on the filesystem (inside .git/refs/). Most filesystems support spaces in directory names, but spaces in command-line arguments require quoting and cause widespread issues with shell scripts, CI/CD pipelines, and git tooling. Hyphens are the universal separator.
What is the difference between fix/ (Conventional) and bugfix/ (GitFlow)?
They serve the same purpose but belong to different conventions. fix/ comes from Conventional Commits terminology, while bugfix/ is GitFlow’s term. Within a team, pick one and use it consistently — mixing conventions on the same repository causes confusion during code review.
Should I include the ticket number at the start or end of the branch name?
At the start of the slug (right after the prefix), so it appears immediately in git branch -a output and is easy to copy. Example: feat/jira-123-add-auth rather than feat/add-auth-jira-123.
Does it matter if branch names are lowercase?
Technically git is case-sensitive on Linux filesystems. However, macOS and Windows are case-insensitive by default, meaning Feature/Login and feature/login would be treated as the same branch. Sticking to lowercase prevents hard-to-debug conflicts when the same team works across different operating systems.
Can I use dots in branch names?
Yes, with restrictions: the name cannot start with a dot, end with a dot, end with .lock, or contain ... Using dots for version numbers (e.g. release/v2.1.0) is a valid and common pattern.
What happens if my generated branch name is too long?
The tool truncates the description slug at the last hyphen within the allowed length, preserving the full prefix and ticket number. If no suitable hyphen is found, it hard-truncates and removes any trailing - or ..
How do I use this branch name in git? Copy the generated name and run:
git checkout -b feat/jira-123-add-user-authentication
# or
git switch -c feat/jira-123-add-user-authentication