Agile Code Branching Workflow for Git 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 iterative development

in principle

• Concise: create as few branches as possible and reduce branch management costs
• Adaptation: Adapt to continuous integration environment
• Stable: Always ensure that the tag version is in a deployable state, the trunk branch is in a testable state, and the development branch is in a runnable state

branch diagram

Two permanent branches

development branch: dev

• The code of the development branch will be automatically built into the development environment continuously, so that developers can conduct self-test and joint debugging of the latest code;
• The development branch is the starting point of all development work, and the end point of requirement feature integration;
• The development branch is the busiest branch, and developers should ensure that the code of the development branch is ready to compile and run;
• The development branch is protected, only repository maintainers can merge code into the development branch, and no one should push code directly to it;

main branch: main

• The master branch is continuously and automatically built into the integration test environment so that testers can test new features;
• The main branch is a relatively stable branch, which should be merged from the development branch after development self-test;
• 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;

Two temporary branches

When developers submit code, be sure to abide by the following principles

1. Create temporary branches from dev or version tags to complete individual feature or issue changes and commit;
2. One feature, one issue, one branch.

thus avoiding:

1. The code can be tracked by requirements and issues;
2. reduce the possibility of conflicts between branches;
3. Feature development and bug fixes can be performed in parallel;
4. Clear version records;
5. When a certain feature or problem code fails to pass the review, it does not affect the return or rollback of other problems.

Feature branch: feature-xxxx

• Feature branches are created by developers based on development branches 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 is developed and tested locally, the author pushes it to the code repository, and the author initiates a merge request to the development 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 is coded and self-tested locally, the author pushes it to the code repository, and the author initiates a merge request to the development branch for repair;
• The merge of the problem repair branch should be checked by the repository maintainer before merging into the development 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 development 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 . {.is-info}

TODO: Find time to train on code merging

release of version

Major Version Label: vx.x

• When the test is completed and the version is ready to be released, it needs to be marked with a version number label;
• 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 there is an online problem in the version of the production environment and needs to be urgently repaired, a patch branch needs to be created 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 online problems of the production environment are repaired and tested, the patch version label needs to be marked on 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. Considering 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 development as appropriate. branch{.is-info}

{{o.name}}

{{m.name}}