Git Branch Naming Reference

Quick reference for EBRAINS branch naming conventions.

Branch Naming Format

Branch Types

TypePurposeExample
featNew features or enhancementsfeat/18-add-user-auth
fixBug fixes (urgent or critical)fix/19-login-bug
hotfixCritical production fixeshotfix/20-security-patch
docsDocumentation changesdocs/21-update-readme
choreNon-functional updates (tooling, dependencies)chore/22-update-deps
refactorCode restructuringrefactor/23-optimize-queries
testAdding or updating teststest/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