Git Workflow Mini Code Branch Workflow

foreword

• This article is derived from the normative guidance for Git branch management of my own team, and does not represent any industry standard
• This workflow is suitable for project code branch management with unit testing as the main component and no integration testing.

in principle

• Concise: create as few branches as possible, reducing branch management costs and collaboration costs
• Fast: keep tag versions ready for release, maintain trunk stability through unit testing and code review

branch diagram

main branch: main

• The master branch automatically builds and runs unit tests continuously;
• The main branch is a relatively stable branch that needs to undergo strict code inspection and unit testing;
• The main branch is protected, only the warehouse maintainer can merge the development branch into the main branch, and the merge behavior is transferred to the test;

The project code without the test link needs to pass sufficient unit testing to ensure the code quality, so there is no development branch

Two temporary branches

Feature branch: feature-xxxx

• Feature branches are created by developers based on the master branch for the development of a single feature;
• Feature branches should comply with the principle of one feature and one branch, which facilitates activities such as code inspection, requirement tracking, and problem analysis;
• Feature branches should be named feature-[需求编号]so that they can be automatically associated with requirements and requirements tracking;
• After the feature branch passes the unit test, the author pushes it to the code repository, and the author initiates a merge request to the main branch;
• The merge of the feature branch should be checked by the repository maintainer before merging into the development branch;

Issue fix branch: fix-xxxx

• Issue fix branches are created by developers based on development branches for single issue fixes;
• The problem repair branch should follow the principle of one problem and one branch, which is convenient for code inspection and problem tracking;
• Bugfix branches should be named fix-[问题单号]so that they can be automatically associated with tickets;
• After the problem repair branch passes the unit test, the author pushes it to the code repository, and the author initiates a merge request to the main branch;
• The merge of the problem repair branch should be checked by the repository maintainer before merging into the main branch;

Supplementary Notes for Temporary Branch Merging

• Between the feature branch and the bug fix branch push, the latest code should be merged from the master branch first;
• The merge strategy is rebase, that is, always put your own commits at the end to keep the version history clear;
• Conflicts should be resolved prudently, using visual tools such as IDEA/WebStorm to merge code, and if necessary, call the conflicting parties to merge in pairs;

The code merge window of the visualization tool, the leftmost is our code, the middle is the original code, and the right is the third-party code; blue is the newly added code, gray is the deleted code, red is the conflicting code, and the red code needs to be handled carefully .

release of version

Major Version Label: vx.x

• When the code in the main branch is evaluated and ready to be released, it needs to be tagged with a version number;
• Major version tags are 小写字母v+主版本号named after v1.0;
• The purpose of the version label is for traceability and association, and the release of the specified version is subject to the label code;

version patch

patch branch

• When the released version has online problems and needs urgent repair, it is necessary to create a patch branch based on the version tag;
• Patch branches are 大写字母V+主版本号named after V1.0;
• Patch branches follow the principle of non-essential creation to reduce the complexity of branch management;
• The patch branch will not create a separate CI environment and test environment for the time being, and will be deployed to the pre-release environment as appropriate in the future;

Patch Version Label: vx.xx

• When the production environment online problems are fixed, unit tested, and code reviewed, the patch version label needs to be affixed to the version branch;
• Patch version tags are 小写字母v+补丁版本号named after v1.0.1;

In order to ensure the simplicity of version management, online problems should be modified in the main version as much as possible, and patches should be released as appropriate. Taking into account the rapid repair requirements of online problems, there is no restriction on the code of the patch version being directly incorporated into the submission of the patch version, and incorporated into the main version as appropriate. branch

{{o.name}}

{{m.name}}