Git branching structureHow to organize Git branches in our repositories.
Table of Contents
- main branch
- dev branch
- feature branches
- task branches (optional)
- release branches (discussion ongoing)
This branch follows the company’s public release schedule . Everything on this branch is official , so any commit landing here must have been validated by a release manager .
Official releases are marked either using git tags or release branches .
When ready, the
dev branch is merged into the
main branch by the release manager.
Commits in this branch have undergone Quality Assurance (QA), they pass unit tests and code style linting. To ensure all this, only the repository maintainers have commit rights into this branch.
Code lands on this branch via GitHub Pull Requests (PR) from
Each branch deals with a single feature . They depart from the
dev branch and go back to it via a PR, ensuring it is peer reviewed and it passes QA, unit tests and code style linting.
Commit early / commit often principle. No special commit message format is enforced in this branch.
Before submitting a PR for merging into
dev , commits in a feature branch shall be rebased to the current
HEAD and squashed into one or several properly formatted commits (See Commit Discipline ).
Feature branches should be deleted after merging them back into
task branches (optional)
When features are big enough they can be divided into tasks .
task branches depart from and, later, merge into their corresponding
feature branch after peer review.
Commit early / commit often principle. No special commit message format enforced.
release branches (discussion ongoing)
Hotfixes are applied to
release branches by release managers after peer review.