Branching rules
We will be using the GitFlow branching model for each repository. For more detailed view on the model you can scroll to the bottom
- Main - protected
- Development - protected
- Feature - to develop new features that branches off the
developmentbranch - Release - help prepare a new production release; (from the
developmentbranch and must be merged back to bothdevelopmentandmain) - Hotfix - hotfix branches arise from a bug that has been discovered and must be resolved as soon as possible. Most of the time it is "quick and dirty" and can cause technical debt
- Bugfix - branches arise from a bug that has been discovered and must be resolved UNLIKE the hotfix - it's not an urgent one. Most likely in
developmentsince it's not urgent. Branches off fromdevelopmentbranch - Rework/Refactor - branches that arise because of technical debt
- Test - branches for experimenting safely on them
All temporarily branches must be in the format: <category/description-in-kebab-case>
The category references the type of development that the developer is going to do in the branch. It is based on the temporary branches.
Example:
- Developer wants to create second factor authentication - feature
- Developer wants to fix bug in production - hotfix
- Developer wants to fix bug in development - bugfix
The short description includes a short description what others should expect to see in the branch (short description of the user story/issue that is going to be implemented)
Example:
feature/two-factor-authbugfix/dark-mode-rework
Temporary branches will inevitably (unless cancelled) be merged in development. There MUST NOT be any direct merges to main from feature/bugfix/test etc. branches. There must be open a pull request for merging to development.
Pull requests are mandatory for each feature (and the rest of temp branches) in order to be accepted in development. Pull requests can be approved, returned for changes, etc. 1 reviewer minimum per pull request. Each pull request must contain the following:
Short description of what is being introduced - 'Feature - Second factor authentication'
Reference the issue that this pull request will close. Details that the reviewer should know (or should be added to the documentation) before testing.
Link any issues that the pull request will close, by using the closing tags e.g. Closes #1
Part for "What should be tested". Checkboxes with short description of the functionality that should be tested.
Refer to the issue that this branch will close/is working on.
Add all team members if not specifically stated otherwise during meeting, stand-up, etc.
Match all labels of the issue it references. Add additional ones if you think that are necessary (technical debt, help wanted, etc.)
Match the milestone to the one of the issue. It refers to the sprint.