Git workflow and branching strat
为 team 制定的一个 Git workflow 和分支的策略，记录一下。
Reference Documents
This workflow and strategy is referred to below two articles from Bitbucket:
Gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Git Feature Branch Workflow https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
Branch types and purpose
There are mainly 5 types of branches serve for different purpose:
- master branch stores the official release history.
- dev branch serves as an integration branch for features.
- Each new feature should reside in its own feature branch.
- defect branch is used to fix a defect during the sprint and that defect is not related to any story of current sprint(historical defect)
- release branch hosts all features for a release.
- hotfix branches are used to quickly patch production releases.
Time points for creating and merging different type of branches
Master and dev branch
master and dev branch should be created when initiate the code repository, normally there is no need to re-create these two branches, and both two branches will not be deleted forever.
Creating & Merging Rule: Dev branch is created based on master branch, and once it contains all features for one release, and meet test pass criteria, then it should be merged to release branch.
Dev Branch
Feature branches
Feature branches should be created by each developer who is the owner of that feature/story, and it might always be created at beginning of the sprint, once developer knows which feature he/she will develop in this sprint.
Creating & Merging Rule: Feature branch is created by each developer and based on dev branch. Once developer completed one feature's development in his/her local environment(includes UT and any other tests conducted by developer), he/she needs to raise a pull request to merge this feature branch to dev branch.
Note: Before raise pull request, developer needs to merge the latest dev branch code to their feature branch and if there are any new codes from dev(other developers pushed ahead of time), developer needs to test it again in their local to ensure all new added features work well, then raise the pull request.
Feature Branch
Defect branches
If developer needs to fix a defect but that defect is not related to any story of current sprint, such as one historical defect which needs to be fixed in current sprint, then defect owner can create a defect branch.
Creating & Merging Rule: Defect owner is responsible to create defect branch and it should based on dev branch, once the fix is tested in local, defect owner needs to raise a pull request to merge the code change from defect branch to dev branch and deploy to dev and testing environment for verify. Once fix is verified, owner needs to delete the defect branch.
It has the same process as feature branch below
Defect Branch
Release branches
Release branch should be created by the deploy owner of that sprint, and it should happen when all that sprint's features meet the test pass criteria on dev and test environment.
Creating & Merging Rule: deploy owner is responsible to create the release branch based on dev branch. Once release branch code is deployed to stage environment and meet test pass criteria, release branch code needs to be merged to master branch, then deleted by the deploy owner.
If there are any code change happened on release branch, that needs to be merged back to dev branch by deploy owner before delete the branch.
When the new release branch is created, the previous version release branch could be deleted.
Release Branch
Hotfix branches
hotfix branch should be created by each developer who is the owner of that defect. Here the defects are referring to the critical(or high priority) defects which detected on stage or production(in the future) and need to be fixed immediately.
Creating & Merging Rule: Hotfix branch should be created based on master branch, and once the fix is deployed to stage or production and verified, then defect owner needs to merge it back to master and dev branches, then delete it.
Note: As currently we don't have a live prod environment, so this hotfix branch should be created based on latest release branch, and needs to be merged back to release branch, then release branch needs to be merged to master and merged back to dev branch.
Hotfix Branch
Branch naming convention
Feature Branch
Feature branch needs to start with "feature/"(there isNO"s" at the end), feature's name needs to follow the pattern sprint#-ownerName-featureName. One example "feature/sprint24-LJC-contractHashHistory"
Defect Branch
Defect branch needs to start with "defect/"(there isNO"s" at the end), defect's name needs to follow the pattern sprint#-ownerName-defect#. One example "defect/sprint24-LJC-123"
Release Branch
Release branch needs to follow the pattern release-V#. One example "release-V0.22"
Hotfix Branch
Hotfix branch needs to start with "hotfix/", fix's name needs to follow the pattern ownerName-issueName. One example "hotfix/LJC-notificationError"
