For project version management, do you have such pain points: there are many project branches and it is not easy to manage, the commit information on the git log interface is messy, complex and non-standard, and the version rollback does not know which version to choose...
The best practice series of project version management, the author will introduce in the form of two articles (ie, basic and advanced). This article is the best practice of gitflow version management-basic article. The basic article mainly introduces the basic process of git application in production and how to use gitflow to manage your project version line (applicable to agile iterative project management scenarios). The advanced part will focus on gitflow+jenkins+docker+DevOps+agile Scrum to complete the continuous construction and continuous delivery (CI/CD) of the project. Reading this article requires a certain git foundation , and the basic knowledge will not be expanded in this article. You can learn a lot of Git basic knowledge by making good use of web surfing tools. In fact, what this article introduces is not pure gitflow , but the transformation and best practices of gitflow combined with actual production.
table of Contents
Three, Gitflow best practices (basic articles)
3.2 Best practice of Gongxing and Akang
3.2.1 Remote trunk branch creation
3.2.4 Merge conflict submission version
3.2.5 Release of test environment
Fourth, the bi-weekly iteration system and gitflow
4.1 Agile two-week iterative system
4.2 Best practices of bi-weekly iteration combined with gitflow
Git basic terms and abbreviations
| the term | Explanation |
| PR | That is, pull request, pull request. Ask the git code manager to merge your code into the branch of the repository. General PR consists of a title part, a description part and a code part. |
| code review | In the PR process, the code administrator conducts a code review on the code you submit, that is, whether your code conforms to the specification, whether there are style problems, security issues, etc. The students who cred your code are not necessarily code administrators, mature In an agile team, every member is a code owner and can review pr. |
| squash | In the PR process, all your commits will be merged (squeezed) into one commit and submitted to the target branch. The purpose is to reduce redundant submissions and standardize the main branch submission information (in fact, it is an operation of rebase). |
| LGTM | Look good to me (looks very hanging), generally exists in PR comments, that is, there is no problem with the content of pr, and agree to merge into the repository. |
One, branch protocol
In our best practice, there are always only three long-term and independent branches in the remote repository . They are develop , release, and master . The three branches correspond to three environments, namely development environment (integrated development environment) and test environment. (Pre-release environment) As with the production environment, the three branches have their respective permissions. You cannot directly push and commit them , that is, all modifications are made through PR to ensure the security and stability of the branch's corresponding environment. The remote branches corresponding to the local environment will be automatically deleted after the PR is passed to ensure the simplicity of the version line.
| surroundings | Branch name |
| Development environment | origin/develop |
| Test environment (pre-release environment) | origin/release |
| Production Environment | origin/master |
| Local environment function branch | develop_xxx (xxx is the specific development member or specific function description, origin/develop_xxx, that is, the feature branch sinks to the local, the life cycle is short, only exists in the pr process). |
Two, version number protocol
Before formally introducing gitflow, we need to standardize the version number to facilitate the development of the following text.
In production, our commonly used version number is a three-digit version number (occasionally with a four-digit hot fix number), and its composition is as follows:
V主版本号.次版本号.功能号(.${热修复版本号}).环境
eg: V1.0.0.1.RELEASE, V1.1.0.DEVELOP, V1.0.0. (The version number is not in decimal, but is pushed according to the iteration plan)
2.1 Major version number (first version number)
The main version number is also called the first version number and the top version number, that is, the first version number after V. The major version number generally represents the number of phases and product direction of the project. Unless the project contract changes, large-scale API incompatibility, product direction changes, and underlying architecture upgrades, it is not easy to update.
In addition, if the project is not officially released, not officially incubated, or officially launched, the first version number will be 0, and the first phase will be V1.
2.2 Minor version number (iteration number)
The minor version number, also called the iteration number, generally represents the set of features released by a certain iteration (one iteration release contains several feature updates).
For example, V1.1.0: release version of the first iteration of the first phase project, V1.2.0: release version of the second iteration of the first phase.
2.3 Function number (PR number)
Generally speaking, the code submitted to the project branch needs to go through PR. In order to ensure the simplicity and purity of a single PR, it is recommended that a PR describes a function. Therefore, the third-digit version number is also called PR number or function number, which is used to describe a single function or code modification submitted to the main branch.
For example, V0.0.1: the first submission of the first iteration, V0.0.98: the 98th PR of the first iteration.
2.4 Hot fix number
The four-digit version number is an optional version number, which is the hot fix version number (also called the master insurance number hh). It does not appear under the regular iteration and develop branch, but often appears in the test environment. The release branch corresponds to the production environment. The master branch (the development environment corresponding to the develop branch has a bug, directly submit pr for repair and add +1 to the original version number). This version number is often used for online hot repair, hot repair of test environment (pre-release environment).
It is worth noting that after the four-digit version number is hot-fixed online, if it is to be synchronized to the local develop environment, one should be added to the three-digit version number under the develop branch.
For example, the hot fix number of the master is V1.0.0.4, and the current version of the develop branch is V1.1.8.DEVELOP, then this repair should be synchronized back to the develop branch to ensure that the bug does not recur, then the version on the develop is V1.1.9 .DEVELOP
2.5 Environment number
Because the tag name in git is unique, then the tag of V1.0.0 appears under the develop branch, so you can no longer type a tag called V1.0.0 under release and master. Therefore, the environment number appears to distinguish the branch versions (the production environment does not add the environment number).
| surroundings | Environment name | Version number (example) |
| Development environment | DEVELOP | V1.0.0.DEVELOP |
| Test environment (pre-release environment) | RELEASE | V1.0.0.RELEASE |
| Production Environment | MASTER | V1.0.0 |
Three, Gitflow best practices (basic articles)
3.1 Overall flow chart
3.2 Best practice of Gongxing and Akang
Here are two students who will be moved out for the next explanation. They are [Gongxing] and [Akang].
3.2.1 Remote trunk branch creation
At the very beginning of the version (referring to V0.0.0), the code manager will initialize the remote warehouse and create three branches based on the initial version of the master. They are
Origin/master (corresponding to production), origin/release (corresponding to the test environment), origin/develop (corresponding to the development environment) and set protection strategies for these three branches, and direct commit and push modifications are not allowed in the three branches.
The code manager will tag the three initial versions with the corresponding TAG: (V0.0.0.DEVELOP, V0.0.0.RELEASE and V0.0.0) .
3.2.2 Local branch creation
After completing the iteration planning meeting (the iteration version number is V0.1.0), Gongxing and Akang respectively claimed two tasks: [Development function] Gongxing and [Development function 2] Akang.
At this time, Gongxing and Akang will clone the remote warehouse and create a local develop_gx branch and develop_kang branch based on origin/develop .
3.2.3 Create PR
After the two claimed the task, they proceeded with synchronous development. After a period of time, Gongxing took the lead in completing the work of [Development Function 1], so he needed to submit the current development version to the development environment for self-test and front-end joint debugging. But at this time [origin/develop] is protected and cannot be submitted directly. Therefore, the bow line needs to make a PR application for the current development version, that is, create a pull request, request the code manager to code review the code, and merge it after approval.
The steps involved here are roughly as follows:
1. Push the current local branch to origin and get origin/develop_gx.
2. Create PR: That is: origin/develop_gx merged into origin/develop pull request
3. Wait for the code administrator (or classmates in the group) to review the code. If you need to modify it, you can directly put forward a comment in the pr. After the author has modified it, push it directly to the remote branch, and continue to wait for the code administrator to perform code review.
4. After passing, merge the current commit list into origin/develop in the form of squash to obtain the commit of V0.0.1.DEVELOP
5. Finally choose to delete the remote branch of origin/develop_gx
At this time, Gong Xing completed the development of the first function, and tagged his pr commit on the [origin/develop] branch: record this commit as [V0.0.1.DEVELOP]
3.2.4 Merge conflict submission version
Soon after, student Akang also completed the development of [Development Function 2], and he also needs to submit the code to the origin/develop branch for testing and joint debugging. But at this time, origin/develop is already different from his base version (the base version is V0.0.0.DEVELOP, the remote version is V0.0.1.DEVELOP, one version ahead) If you create a PR directly, it may be due to code conflicts. Unable to complete the version merge, as shown below.
At this point, Akon needs to pull the origin/develop version locally and perform the following operations (it is recommended to directly use the git tool that comes with ide, which will be a lot more convenient)
//检查远程仓库是否有新版本
git fetch origin
//发现新版本，需要拉取到本地解决冲突后进行代码合并
//暂存本地修改
git stash save “stash changes”
//拉取远程版本
git pull origin/develop
//取出本地修改
git stash apply
//手工解决冲突(推荐直接使用idea)
//提交修改
git commit -m'1、解决冲突合并版本'Use the conflict resolution tool that comes with ide as shown below
After submitting the modification (note that you must discuss the code changes with the author of the conflicting code) , you can create a PR and wait for the students in the team to review the code. After the team members pass, Akon's modifications can be successfully merged into origin/develop for joint debugging and testing. At this time , Akang needs to tag the change commit [V0.0.2.DEVELOP] , as shown below.
So far, the development work planned by V0.1.0 has been completed.
3.2.5 Release of test environment
After completing the development of the V0.1.0 version, Gongxing students claimed a new task: [V0.1.0 version mention]. Gongxing students who are doing other functional development work need to stash the local code, merge the code of the origin/develop branch with the local code (that is, the git pull origin develop operation), and resolve the code conflict.
Because the code is to be released to the origin/release branch for version testing, Gongxing needs to merge the code on origin/release with the local code at the same time (that is, git pull origin release operation) and resolve the code conflict.
After completing git pull origin develop and git pull origin release, a new commit version will be formed locally. Gongxing students need to merge this commit version to origin/release through pr in order to complete the release of the test version of the release branch. Therefore, Gongxing students need to repeat the PR creation process of step 3.2.3 and pass the approval of the branch administrator of the release branch before releasing the version to the test environment.
3.2.6 Version Mark
After submitting the commit to the release in the form of pr, the next step is the process of marking the version, because this release has completed the development of the version, so the current version will be marked as [V0.1.0.RELEASE on the release branch ]. And because on the develop branch, the V0.0.2.DEVELOP version corresponds to the release V0.1.0.RELEASE version, the commit on the origin/develop branch will be marked with a second tag: [V0.1.0.DEVELOP] .
Then, for the tag processing of the develop branch, it will continue directly from V0.1.0.DEVELOP (such as V0.1.1.DEVELOP, etc.)
3.2.7 Hot repair
The origin/release branch corresponds to the test environment. In some cases, the test environment is equivalent to the beta version of the project, which may directly face customers.
Then after the version is tested, the test students have conducted various tests on the [V0.1.0.RELEASE] version and found that there are bugs in the current version, then the developing students must hot fix the bugs.
Assuming that there is a bug in the test environment, and the repair work of the bug is still claimed and solved by Gongxing, then Gongxing needs to suspend the development work on hand (git stash), and then pull the latest version of origin/ The release branch to the local, and then bug fixes. After completing the repair, submit the local code to the origin/release_hotfix_gx branch, perform PR operations on the branch, and the release administrator will perform code review and merge into the release, and record the repair version as [V.0.1.0. 1 .RELEASE ].
Of course, because the branch commit has a mapping relationship, the BUG that appears on V0.1.0.RELEASE will definitely appear in V0.1.0.DEVELOP. So at this time, the version of the repaired test environment is still not enough, and the repair needs to be merged into origin/develop. Therefore, Gongxing students need to pull the newly released version [V0.1.0.1.RELEASE] to the local, and then submit the version to origin/develop to form [V.0.1.1.DEVELOP]
At this point, the hot repair process is completed (the master hot repair is also the same, but the repair version is merged into the release and develop according to the actual situation).
3.2.8 Production release
After completing the release version testing and BUG repair work, Gongxing students need to publish the release branch version to the master to complete the release of the production environment version. In fact, this process is not much different from 3.2.5. Students can combine their actual situation to add team code review, checklist inspection, release risk control and other operations in this step to ensure the safety of production release.
After completing the release of origin/master, update the master's tag to V0.1.0 to complete the release of the entire iteration.
Careful students may have discovered that the three branches of origin/develop, origin/release, and origin/master are independent of each other during the whole process and do not affect each other. Therefore, this workflow belongs to the gitflow of the three-independent branch mode, students If we want to reduce the process, the release branch can be optimized and tested directly on the develop branch (also in line with test-driven development)
Fourth, the bi-weekly iteration system and gitflow
4.1 Agile two-week iterative system
Imagine a scenario: the product does not have much time to plan the features; the project hastily planned the backlog; the development completed the development work on the last day of the iteration, and the test only had the last 2 hours to test; after the launch, a bunch of bugs would make people very crazy, so bi-weekly iteration The system came into being.
The following figure is an example. There are three vertical functional roles in an agile team (products are not considered for the time being): development, testing, and project (Scrum master) . We assume that the current iteration is N , the next iteration is N+1 , and the previous The iteration is N-1 .
Two-week iterative system, that is, a sprint iteration is set to two weeks (or several weeks). In the first week of these two weeks, these vertical functional roles can be divided as follows:
- Development: carry out N iteration (current iteration) development and N-1 version (previous version) hotfix work, and conduct unified testing every Friday;
- Testing: Perform N-iteration (current iteration) development environment testing and N-1 iteration (last iteration) release environment testing, and complete N-1 version testing before every Friday;
- Project: Carry out N+1 (next iteration) iteration planning work and the previous two iterations (N-2) iteration release work
In this way, N-1 version, N version, N+1 version can be staggered, orderly (a steady stream of demand comes from hhh) Of course, iterative development time and test time can be changed appropriately (such as development: test = 6 :4 or 7:3).
The advantages of using bi-weekly iterations are:
- Development students have sufficient and flexible time for iterative development work, bug fix work and demand understanding
- Test students have enough time to test work to ensure the quality of the project (test one function in the develop environment, and complete functional tests in the release environment)
- The project has more time to plan the iteration of the project and decompose specific requirements to make a more complete design (crazy planning iteration).
4.2 Best practices of bi-weekly iteration combined with gitflow
Gitflow version management based on the bi-weekly iteration system, that is, in the iteration:
- Develop on origin/develop, carry out the development work of 3.2.4 step, and work with the hotfix of the previous release version;
- The test follows the development of the test of the develop branch and the test of the previous release version;
- At the end of the first week, release the version to origin/release in a unified manner, and start the functional test of the current release environment in the second week;
- On Monday of the third week, the project will release the version (that is, release to origin/master)
5. FAQ
Q1: Under the microservice architecture, how can the version number be unified for each project with an independent version library? Is it a separate version number for each microservice or a unified version number globally?
A1: For each microservice independent version library under the microservice architecture (or distributed architecture project), it is recommended to compile the version number globally, that is, the same release window, for all target release branches and two-digit version numbers Compile (ie, the global unified iteration number or product number). For microservices that have not been updated, Tag release can be made directly on the commit of the original release.
Q2: The three-branch version line is relatively independent, which is more painful for version merging.
A2: This problem is real. It is recommended to fix the publisher and keep the merge records of the release branch, master branch and develop branch in the local branch to prevent excessive conflicts.
Q3: For the target release function, if the function is at risk before release, the risky branch cannot be released.
A3: The problem is real, and it can be released with switch configuration and bi-weekly iteration.
Q4: The project is in the rapid development stage. Everyone keeps mentioning PR to the develop branch, but no one does code review.
A4: You can try the PR title with tag information as the commit title, that is: V0.0.1 xxx function development V0.0.2 XXX function development, in this way, it is equivalent to a resource lock, and everyone wants to mention pr on develop. But the previous person took up the three-digit version number, then someone needs to dispose of this pr before you can use the next version number until the team’s code review habits are mature, as shown in the figure below (Is the develop version line very clear?) .
Q5: Are the three branches of origin/develop, origin/release and origin/master allowed to merge with each other?
A5: Not allowed, only branch version merge in the form of PR
Q6: After using this kind of gitflow, what will the version lines of the three branches look like?
A6: As shown in the figure below, whether it is the develop branch or the release branch and the master branch, the branch will always have only one straight line, and there will be no merging between branches, so it appears that the version line is very clean and tidy.
Q7: It seems that the feature branch is not seen in the whole process
A7: Yes, in this type of version management, the feature branch has actually been sunk into everyone's local version library, not directly reflected in the origin library.
Q8: Can the remote feature branch not be deleted?
A8: In order to ensure a clean git log, it is recommended to delete the personal branch after merging into the develop branch, but it is also possible not to delete the remote personal branch. You can try to complete the pr of develop and use the same personal branch to merge into release_${version} , And then execute the PR of release_${version}->release to complete the release release.
The above is the best practice of project version management: all the content of gitflow basics, welcome to discuss and put forward suggestions for improvement in the comment area!