Our methodology is mostly inspired from git-flow which basically allows to separate works by branch types: feature, bug, chore and release.
kebab-casefor branches names.
# Bad feature/list_job_positions Bug/userResetPassword # Good feature/list-job-positions bug/user-reset-password
Use the forward slash
/to separate the branch type from the branch title.
# Bad feature-list-job-positions bug_user-reset-password # Good feature/list-job-positions bug/user-reset-password
Find a balance between conciseness and descriptiveness for branch titles. Think that you and other developers can distinguish easily each branch.
# Bad feature/as-a-user-i-can-logout bug/as-an-admin-when-i-select-a-menu-item-i-see-a-highlight # Good feature/user-logout bug/admin-menu-item-highlight
Prefix the branch title with the backlog item ID when using project management tools such as Clubhouse and JIRA. The aforementioned tools require it for their Git integration to function. While other tools rely, such as Pivotal Tracker, rely on the commit message content to include the backlog item ID.
# Bad ch-6862/feature/list-job-positions # Good feature/ch-6862-list-job-positions
By default, there must be 2 branches:
develop. Both branches must be created when setting up the code repository.
mainbranch is the version in production.
developbranch is the version currently on the staging environment.
No one should commit directly to either the
Avoid commit history rewrites on either the
developbranch at all costs as it could leave the project in a dire state.
All feature, bug and chore branches must be checked out locally from the
developbranch. By avoiding branching more than one node away from the main branch, we can easily avoid complex conflicts and rebasing which can take hours or days to solve.
The definition of what constitutes a feature, bug or chore depends on the user story type. No code should be committed if there is not a user story for the tasks at hand.
Once merged, feature, bug and chore branches should be deleted to keep only the default and active branches.
Release branches must be checked out locally from the
Releases branches are required when opening a pull request to merge code into the
mainbranch. No code is merged directly into the
The name for release branches must contain the corresponding semantic version number.
# Bad release/1.0 release/v1.0 # Good release/1.0.0