Git Branch Naming Reference
Quick reference for EBRAINS branch naming conventions.
Branch Naming Format
Branch Types
| Type | Purpose | Example |
|---|---|---|
| feat | New features or enhancements | feat/18-add-user-auth |
| fix | Bug fixes (urgent or critical) | fix/19-login-bug |
| hotfix | Critical production fixes | hotfix/20-security-patch |
| docs | Documentation changes | docs/21-update-readme |
| chore | Non-functional updates (tooling, dependencies) | chore/22-update-deps |
| refactor | Code restructuring | refactor/23-optimize-queries |
| test | Adding or updating tests | test/24-unit-tests |
Examples
With Task ID
With Descriptive Name
With Scope and ID
Common Commands
Create and Switch to New Branch
List Branches
Switch Between Branches
Delete Branches
Rename Branch
Workflow Examples
Starting New Feature
Fixing a Bug
Updating Documentation
Best Practices
Do
- Use lowercase letters
- Use hyphens to separate words
- Include task/issue ID when available
- Keep names concise but descriptive
- Use consistent prefixes (feat, fix, docs, etc.)
Don’t
- Don’t use spaces in branch names
- Don’t use special characters (except hyphens and slashes)
- Don’t make names too long (max ~50 characters)
- Don’t use uppercase letters
- Don’t create branches directly from other feature branches (use main)
Protected Branches
In EBRAINS projects, these branches are typically protected:
- main - Primary branch, requires merge requests
- develop - Development branch (if using GitFlow)
- production - Production releases (if separate from main)
You cannot push directly to protected branches. Always use merge requests.
Troubleshooting
Branch Already Exists
Accidentally Created Branch with Wrong Name
Forgot What Branch You’re On
Related Documentation
- How to Git Commit - Branching strategy section
- First Contribution Tutorial - Complete workflow
- Git Commit Reference - Commit conventions