| Branch Type | Branch | Description, Instructions, Notes |
|---|---|---|
| Code Flow | release | This is the main branch for production. |
| master | Base branch should always be release | |
| Temporary | feature | Base branch should always be master. |
| bugfix | Base branch should always be master. | |
| hotfix | Base branch should be release. | |
| doc | Base branch should always be master. |
In any software, every day many branches are created and pushed to the GitHub repository. Having a manageable code repository is important and mandatory when working with a team.
ColoredCow Portal uses branch naming conventions to work with git repositories. In this convention, the branches are divided into two categories:
These branches which we expect to be permanently available on the repository follow the flow of code changes starting from development until the production.
All new pull requests related to features and bug fixes shoulb be merged into this branch after code reviews. Resolving developer codes conflicts should be done as early as here.
This is the main branch for production. Nothing should be directly pushed into this branch except for the hot-fix errors and the master branch after the complete testing of the issues or bug fixes.
As the name implies, these are disposable branches that can be created and deleted by need of the developer or deployer.
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/21/
- feature/30/dark-theme
- feature/modulename/30/add-nickname
It is recommended to use all lower caps letters and hyphen (-) to separate words unless it is a specific item name, ID or a module name. Forward slash ('/') could be used to separate the ID and description. If there are changes that are affecting another repository also then again a forward slash ('/') should be used to specify the module or repository the issue belongs to.
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/change-color
- bugfix/21/mail-not-sending
If there is an issue in the release branch then it needs to be fixed immediately, then that issue should be created as a Hotfix. The hotfix branch should be pulled from the release branch.
Examples:
- hotfix/disable-endpoint-zero-day-exploit
- hotfix/increase-scaling-threshold
If there is a need to create a new readme/documentation file or do some changes to an existing document, then the branch prefix will be doc/.
Examples:
- doc/naming-conventions