GitHub Flow - locbud/Dalton-Brothers GitHub Wiki
In this section, we summarise some key points about GitHub flow which our team will follow to make sure that the our personal and team use of Github will be consistent, effective, efficient and importantly simple enough to carry out (More details with thorough explanations about GitHub flow can be found in the articles listed in the references).
-
Master is always deployable.
-
Branch whenever working on a new feature, a new enhancement or a new fix. New branch must be created off of master. Branch naming conventions are mentioned at the bottom of the page.
-
Commit locally and push your work to the server regularly (to the branch you are working on, not to master).
-
Make pull requests with the following reasons:
- Needing feedbacks.
- Needing helps or discussions
- Being ready to merge, needing QA review from peers in team.
(Vote with ⅔ majority for common consensus - important ones should be discussed with our supervisor or client).
-
Once:
- the pull request review has been complete with all problems being correctly resolved,
- the change or feature has been signed off by the product owner,
- and the branch passes Continuous Integration (CI),
the one who worked on that branch is then allowed to merge his work to the master for a deployment.
Note: This GitHub flow is applied to all research/documenting and project development works, except that we do not have CI for research work, prototyping or documenting stuff (instead we have checklists for them). This GitHub flow must be applied to all of these kinds of work to ensure master branch is always safe under any circumstance.
Branch Naming Conventions:
- Be descriptive.
- Use hyphen to separate word tokens.
- Start branch name with what kind of the work is (e.g.research, develop, prototype, document).
References: