Code branching structure

The structural specifications that code branches need to follow

Branch type Naming conventions To create a Incorporated into the Disallow merging into Commit the prefix purpose limit Testing phase Whether CI is covered
master master There is no There is no All of the other Prohibit the commit
  • Represents the latest set of releases to the public
  • A stable running release
Only the Release and Hotfix branches The acceptance test is
develop dev
  • master
  • release
release master
  • ID of the development task order
  • The Bug list ID
The dev branch is the development branch before the official release Once the initial development phase is complete and a release is produced, the dev branch needs to be removed Unit testing On demand
feature feature_yyyymmdd_featureName
  • dev
  • release
dev
  • master
  • release
  • ID of the development task order
  • The Bug list ID
A single module development branch of the development version Divide modules according to requirements, and try to make each feature branch function independent Unit testing On demand
release
  • The release_YYYYMMDD_ version number is available for frequently updated items
  • Projects with long iterations can use release – version numbers
master master There is no Prohibit the commit
  • Created after dev branch development is complete
  • Specifies the release of the project
  • Specify the acceptance test branch of the project
  • Created based on the latest master
  • Only the dev branch can be joined
  • Bugfix is a combination of feature or hotfix
  • Must have a tag
  • In principle, it should be merged back into the Master branch (except for some project-specific branches)
The acceptance test is
hotfix hotfix_bugid_yyyymmdd
  • master
  • release
  • master
  • release
There is no Prohibit the commit
  • Hotfix is a branch that can be online
  • In principle, it can be created from master, but in certain cases it can be created from Release
  • Created from the latest master/release
  • After acceptance, merge back to the Master or Release branch
The acceptance test is

Schematic diagram of branch management specification

Simple branch management diagram

The above specifications are suitable for large projects with a large number of personnel. In order to avoid the problem of code confusion caused by non-standard operations such as branch naming, merging and code pulling, the code branch specifications are set more complicated. If the project is in its infancy and there are few developers, it can also be managed in the following way: