Git Branch Naming Convention

Working on a big company with projects that could scale from a one-man team then suddenly to a 20 developers team, having a manageable code repository is a need. Most Proof of Concept projects start with a repository with all changes being applied directly to the master branch. Elevating one into a proper big scale repository is a common path being taken by new developers when their small-scale project is suddenly noticed.

On my end, having to work on dozens of different projects like these, I came up with this branch naming convention.

I separated these branches into two categories:

Code Flow Branches

These branches which we expect to be permanently available on the repository follow the flow of code changes starting from development until the production.

• Development (dev)

  All new features and bug fixes should be brought to the development branch. Resolving developer codes conflicts should be done as early as here.

• QA/Test (test)

  Contains all codes ready for QA testing.

• Staging (staging , Optional)

  It contains tested features that the stakeholders wanted to be available either for a demo or a proposal before elevating into the production. Decisions are made here if a feature should be finally brought to the production code.

• Master (master)

  The production branch, if the repository is published, this is the default branch being presented.

Except for Hotfixes, we want our codes to follow a one-way merge starting from development > test > staging > production.

Temporary Branches

As the name implies, these are disposable branches that can be created and deleted by need of the developer or deployer.

• Feature

  Any code changes for a new module or use case should be done on a feature branch. This branch is created based on the current development branch. When all changes are Done, a Pull Request/Merge Request is needed to put all of these to the development branch.

  Examples:

  • feature/integrate-swagger
  • feature/JIRA-1234
  • feature/JIRA-1234_support-dark-theme

It is recommended to use all lower caps letters and hyphen (-) to separate words unless it is a specific item name or ID. Underscore (_) could be used to separate the ID and description.

• Bug Fix

  If the code changes made from the feature branch were rejected after a release, sprint or demo, any necessary fixes after that should be done on the bugfix branch.

  Examples:

  • bugfix/more-gray-shades
  • bugfix/JIRA-1444_gray-on-blur-fix

• Hot Fix

  If there is a need to fix a blocker, do a temporary patch, apply a critical framework or configuration change that should be handled immediately, it should be created as a Hotfix. It does not follow the scheduled integration of code and could be merged directly to the production branch, then on the development branch later.

  Examples:

  • hotfix/disable-endpoint-zero-day-exploit
  • hotfix/increase-scaling-threshold

• Experimental

  Any new feature or idea that is not part of a release or a sprint. A branch for playing around.

  Examples:

  • experimental/dark-theme-support

• Build

  A branch specifically for creating specific build artifacts or for doing code coverage runs.

  Examples:

  • build/jacoco-metric

• Release

  A branch for tagging a specific release version

  Examples:

  • release/myapp-1.01.123

  Git also supports tagging a specific commit history of the repository. A release branch is used if there is a need to make the code available for checkout or use.

• Merging

  A temporary branch for resolving merge conflicts, usually between the latest development and a feature or Hotfix branch. This can also be used if two branches of a feature being worked on by multiple developers need to be merged, verified and finalized.

  Examples:

  • merge/dev_lombok-refactoring
  • merge/combined-device-support

Any organization can come up with their own convention. This applies to my current Team's need and there could be a better approach which could improve upon these. What are your conventions on your own organization?