A bit of background…
The current branching strategy used in Komodo Core is somewhat informal. The idea is to formalize ideas so that everyone agrees on the procedures to follow, and those coming after us know what should be followed.
This is a living document. If the procedures below do not serve their intended purpose, they (or portions of them) should be replaced.
Why this and not that?
There are a number of branching strategies available. This Komodo Core branching strategy is heavily based on Git Flow. This was chosen because the existing strategies match the style of the code base (long lived branches, multiple versions deployed and supported, etc.).
How it works
There are a number of long-lived branches within the Komodo Core repository. The primary ones are:
- master – The main production branch. This should remain stable and is where code for official releases are built.
- dev – The development branch. This is where work is done between branches. Non-hotfix bug fixes and new features should branch off this branch.
- test – The branch for the testnet. As the codebase stabilizes before a release, the code is merged from dev to test.
- hotfix – After a release, a hotfix branch may need to be created to fix a critical bug. Once merged into test and master, it should also be merged into dev. These branches should not be long-lived.
Each release for testnet and production should be tagged. The versioning strategy is not currently part of this document.
Reviewing / Merging
Before a feature or fix is merged into a parent branch, reviews must be approved by repository maintainers. Anyone can review, but approvals from 2 repository maintainers must be completed.
Once approved, it is best (if possible) that the author of the feature or fix merges their branch into the parent branch. Once the merge is completed locally and all unit and CI tests pass, the code is pushed to the parent branch.
Note: It is best to not use the merge feature of the GitHub web interface. Perform the merge locally and push to the server.