preface
With the popularity of Git, more and more teams are migrating or transforming to Git. In the early or middle stage of team construction, an appropriate Git branch management strategy can better improve team efficiency, save personnel costs, and reduce the risks brought by code version management. The author has experienced problems such as code version confusion due to inappropriate branch management strategy, improper personnel operation, and inconsistency between online version and production version. This paper aims to sort out and summarize several Git branch management strategies and discuss and analyze the applicable scenarios. At the same time, we sincerely hope that you can put forward correct questions and discuss more suitable solutions together.
Contents summary
This paper will analyze Git Flow, GitHub Flow and GitLab Flow, three popular workflow models, and summarize the advantages and disadvantages and application scenarios of each model
Git Flow
Process analysis
The Git Flow model declares the following five branches:
- Master is aligned with production and is also a branch of publication (merge permissions are strictly controlled)
- Develop a stable branch that keeps up to date on development based on what the Master checks out (you need to control merge permissions)
- Feature Branch A Branch that checks out features based on Develop and is used for Feature development. After Feature development is complete, the Branch is merged into Develop
- Release Branch A pre-release Branch that is checked out by the Develop Branch and used for pre-release testing. After testing is complete, the Branch is merged into the Develop Branch and merged into the Master Release
- Hotfix Branch Hotfix Branch is a Hotfix Branch that is used to fix production bugs that are checked out by the Master and then merged into Develop and Master releases, marking the version Tag
Brief Description of development Process
Single requirement development:
- By default, there is a Master, Develop branch, which checks out Develop based on Master during project initialization.
- The developer receives the requirement to Develop Feature A and checks Feature -A from Develop to Develop Feature A
- After Feature A is developed, merge Feature -A branch into Develop branch and conduct preliminary tests
- Check out the release-a branch from Develop for testing, regression testing, and bug fixing
- Merge the tested release-a branch into Develop, merge it into the Master Release, and label the Release
- When bugs occur in production, check out the hotfixbug branch from master to fix the bugs, merge the fixes into Develop, merge them into Master releases, and tag them with the version
Parallel development of multiple requirements: Merge Develop into Feature A at the right time to avoid the risk of multiple versions crossing over into Feature A. If there is a problem, expose it in advance.)
Special Scenario Analysis
Scenario 1: Feature A and Feature B are scheduled to be online at the same time at A certain point, and Feature A and Feature B have been merged to Develop, and the Release branch will be checked out for testing. Develop contains the code solution for Feature — B: Roll back Develop to the previous version and remerge Feature — A into Develop
Advantages and disadvantages analysis
Advantages:
- Independent functional branches, do not interfere with each other, independent development, testing
- When Feature branches are long, advance Release can be avoided
- Ability to release multiple versions
Disadvantages:
- The model is relatively complex, and we maintain the Master and Develop base branches. If there is a bug in regression or production, we merge the Master branch and merge it back to Develop at the same time
- When there are too many parallel feature branches, the possibility of code conflicts increases
- Branch contamination occurs when multiple requirements are developed in parallel, as in the case of special scenario 1
GitHub Flow
Brief Description of development Process
- Master branch exists by default, consistent with production (GitHub Flow model default branch updates are consistent with product release)
- Develop requirement A, check out branch A based on master
- A after the requirements are developed, submit the merge request to master
- Review merge code and process merge requests (you can continue to submit them until they are processed)
- Release master multiple requirements development in parallel: This is also consistent with the development of a single requirement, except that the conflict needs to be resolved by the Master. It is possible that multiple requirements branches are merged into the Master and regression testing is required
Special Scenario Analysis
Scenario 2: After A branch is developed, it is merged into master, but it cannot be released to production due to various reasons. At this time, the production environment and master code are inconsistent. Solution: Create a product branch from master and merge product scenario 3 only after the master code has been published successfully: In a scenario where multiple requirements are developed in parallel, these functional branches need to be tested in parallel. Assuming THAT I provide the functional branch as a test branch to the test team, it may be necessary to have multiple test environments. Assuming that the master test branch is used as the test branch, it will be contaminated by other merged into the Master branch
Solution: Control quality and improve master access standards
Advantages and disadvantages analysis
Advantages: Simple operation and continuous release
Cons: Not so friendly for testing
GitLab Flow
Brief Description of development Process
- The GitLab Flow development branch is the “upstream” of the pre-delivery branch, which is the “upstream” of the production branch. Code changes must be developed from “upstream” to “downstream”. As shown in the first picture above, the most upstream MASTER is used as the development branch. Only after the development branch is completed and the access conditions for the next stage of submission are met, can the code be merged into pre-production
- The project continues to be released, assuming that the Dev branch is checked out from the PRODUCTION branch at the beginning of an iteration version, and then the upstream Dev is merged with the downstream SIT, UAT and pre-production after the test and acceptance meet the access requirements. Finally, the project is released and merged into PRODUCTION
- Project releases, as shown in Figure 2, are checked and published from the master branch and maintained continuously after minor releases are updated.
Special Scenario Analysis
Scenario 4: Suppose a function branch is transferred to an intermediate node such as UAT, but some of the required code is temporarily undecided, which may pollute the UAT code
Solution: Roll back this code and keep the midstream branch as clean as possible
Advantages and disadvantages analysis
Advantages:
- The solution covers both “release” and “continuous release”
- The ability to differentiate between environmental releases and support the test team disadvantages: there is a risk of contamination of the midstream branch
Diagram of r&d workflow based on GitLab Flow
conclusion
Git branch management strategy scheme, according to the characteristics of the team as far as possible to choose low complexity scheme, for example: in the team with less parallel needs, do not need to release based on version, can choose GitHub FLow model; GitLab Flow model can be selected for strong test environment requirements; In large teams with highly skilled developers and tight controls, Git FLow is a good example. In the process of scheme determination, do not just apply the model, but on the basis of the model, according to the characteristics of the team to develop a simpler, more efficient, low risk factor scheme. This article analyzes and summarizes three Git branch management strategies, hoping to inspire you to choose and specify a version management scheme.