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.
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 (develop)
All new features and bug fixes should be brought to the development branch. Resolving developer code conflicts should be done as early as here.
- QA/Test (testing)
Contains all codes ready for QA testing.
- Staging/UAT (staging, Optional)
It contains tested features that the stakeholders wanted to be available either for a demo or a proposal before elevating into production.
Decisions are made here if a feature should be finally brought to the production code.
- Master (master - Production Go Live)
The production branch, if the repository is published, is the default branch being presented.
Except for HotFixes, we want our codes to follow a one-way merge starting from develop > testing > staging > production.
Temporary Branches
As the name implies, these are disposable branches that can be created and deleted by the need of the developer or deployer.
It is recommended to use all lower caps letters and hyphens (-) to separate words unless it is a specific item name or ID. Underscore (-) could be used to separate the ID and description.
- 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 into the development branch.
Examples:
feat/{TASK-ID}-integrate-swagger-test-API
feat/{TASK-ID}-support-dark-theme
- 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:
bug-fix/{TASK-ID}-fix-gray-on-blur
- Hot Fix
If there is a need to fix a blocker, do a temporary patch, or 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 into the development branch later.
Examples:
hot-fix/{TASK-ID}-disable-endpoint-zero-day-exploit
hot-fix/{TASK-ID}-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/{TASK-ID}-dark-theme-support
- Build
A branch specifically for creating specific build artifacts or for doing code coverage runs.
Examples:
build/{TASK-ID}-permissions-metric
- Release
A branch for tagging a specific release version.
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.
Examples:
release-v1.0
release-v1.1.0
release-v1.2.0
- 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/{TASK-ID}-dev-lombok-refactoring
merge/{TASK-ID}-combined-device-support