Low preface
This document is written to facilitate multi-party collaboration and for multi-branch development management. (Not using online deployment platform such as Teambition)
● Branch type
Master: The master branch, used primarily to integrate code. Dev: The daily development branch, which normally holds the latest code for development. Feat: Specific feature development branch, only interact with develop branch. Release: The Release branch can be considered an untested version of the Master branch. For example, if a phase of functionality is fully developed, the dev branch will be merged into the Release branch, the tests will be fine and the release date will be merged into stable and released. Hotfix: The online bug fix branch. Stable: stable version branch.
● Branch naming
- Primary branch * => master
Definition: source branch of requirement branch, continuous integration stable branch.
- Demand branch
Definition: the individual branch of a developer within a release
Naming: Version number/branch type/Requirement name/personal nickname (optional)
For example, 1.3/feat/ alformative -test 1.3/feat/ alformative -test/geekftz
- Development Branch
Definition: a merge branch of multiple developers in a release that is submitted to the test branch after the merge smoke passes.
Naming: version number/branch type
For example: 1.3 / dev
- Test branch
Definition: a branch that is tested by testers and submitted to when the development branch merges well.
Naming: version number/branch type
For example: 1.3 / release
- Stable branch
Definition: The final stable code for each release.
Naming: version number/branch type
For example: 1.3 / stable
- Patch branch
Definition: Online problem repair.
Naming: version number/branch type/patch name
For example: 1.3 / hotfix/fix – some – problem
- Optimization branch
Definition: Function optimization.
Naming: version number/branch type/optimization name
For example: 1.3 / hotfix/fix – some – problem
● Branch conflict
- Before requirement development, confirm with team members the public files that may be modified or others’ development files to avoid conflicts caused by modifying the same file at the same time.
- When a conflict occurs, find the owner of the conflicting code to confirm and modify it.
- Synchronize the primary branch code in time when the branch lags behind the primary branch.
● Branch merger
- To merge the code of the test branch and prod branch, run the git command to merge the code. The reverse merge code cannot be merged into the feat branch, dev branch, or hotfix branch. Otherwise, the development branch may be polluted.
- Notify group members to update integration branch code (such as release branch) in a timely manner prior to code merging.
Low version of the tag
- Tag the current stable branch each time it goes online without problems.
- The tag description section records version iteration details.