10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

Time:2021-9-15

preface

For project version management, do you have such pain points: many and complicated project branches are difficult to manage, the commit information on the GIT log interface is disordered, complex and nonstandard, and you don’t know what version to choose for version fallback.

The best practice series of project version management will be introduced in the form of two articles (i.e. basic and advanced). This article is the best practice foundation of gitflow version management. The basic chapter mainly introduces the basic process of GIT application in production and how to use gitflow to manage your project version line (applicable to the project management scenario of agile iteration). The advanced part will focus on gitflow + Jenkins + docker + Devops + agile scrum to complete project continuous construction and continuous delivery (CI / CD).Reading this article requires a certain git foundation, the basic knowledge is not expanded in this article. You can learn many basic knowledge of GIT by making good use of Internet surfing tools. actually,This article is not about pure gitflow, but the transformation and best practice of gitflow combined with actual production.

Basic terms and abbreviations of GIT

term explain
PR That is, pull request. Ask the GIT code administrator to merge your code into the branch of the repository. General PR consists of Title part, description part and code part.
code review In the PR process, the code manager reviews the code you submit, that is, whether your code conforms to the specification, whether there are style problems, security problems, etc. the students who CR your code are not necessarily code managers. In a mature agile team, every member is a code owner and can review pr.
squash During PR, all your commits will be merged (squeezed) into one commit and submitted to the target branch to reduce redundant submission and standardize the submission information of the main branch (actually an operation of rebase).
LGTM Look good to me, which generally exists in PR comments, that is, there is no problem with the content of PR and agrees to merge it into the version library.

1、 Branch protocol

In our best practice, remote version LibrariesThere are always only three long-term and independent branches, they aredevelopreleaseAndmaster, the three branches correspond to three environments, namely, development environment (integrated development environment), test environment (pre issuance environment) and production environment. The three branches have permissions respectively and cannot be accessed directlypushAndcommitOperation, that is, all modifications are made through PR to ensure the security and stability of the environment corresponding to the branch. The remote branches corresponding to the local environment will be deleted automatically after the PR passes, so as to ensure the simplicity of the version line.

environment Branch name
development environment origin/develop
Test environment (advance environment) origin/release
production environment origin/master
Local environment function branch develop_ XXX (XXX is a specific development member or specific function description, origin / development_xxx, that is, the feature branch sinks locally, has a short life cycle, and only exists in the PR process).

2、 Version number protocol

Before formally introducing gitflow, we need to standardize the version number to facilitate the next text.

In production, our commonly used version number is a three digit version number (occasionally with a four digit thermal repair number), which is composed as follows:

V major version number. Minor version number. Function number (. ${hot repair version number}). Environment

eg:V1.0.0.1.RELEASE、V1.1.0.DEVELOP、V1.0.0。(the version number is not decimal, but pushed according to the iteration plan)

2.1 major version number (first version number)

Major version number, also known as the first version number and 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. It is not easy to update unless the project contract changes, large-scale API incompatibility, product direction changes, underlying architecture upgrades, etc.

In addition, if the project is not officially released, incubated or launched, the first version number is 0, and if it is released in phase I, it is V1.

2.2 revision number (iteration code)

The minor version number, also known as iteration code, generally represents the function set released in an iteration (an iteration release contains several function updates).

For example, V1.1.0: the first iteration release version of phase I project, and v1.2.0: the second iteration release version of phase I project.

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 one PR describe one function. Therefore, the third digit version number is also called PR number or function number, which is used to describe the 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 thermal repair number

The four digit version number is an optional version number, which is the hot repair version number (also known as master warranty number HH). It does not appear under the conventional iteration and development branch, but often appears in the release branch corresponding to the test environment and the master branch corresponding to the production environment (if there is a bug in the development environment corresponding to the development branch, directly submit PR repair and add + 1 to the original version number). This version number is often used for online hot repair and hot repair of test environment (pre release environment).

It is worth noting that after online hot repair, if you want to synchronize the four digit version number to the local development environment, you should add one to the three digit version number under the development branch.

For example, if the hot repair number of the master is v1.0.0.4 and the current version of the development branch is v1.1.8.develop, the repair should be synchronized back to the development branch to ensure that the bug does not recur, then the version above development is v1.1.9.develop

2.5 environment number

Because the tag name in Git is unique, if a v1.0.0 tag appears under the development branch, you can’t type another 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).

environment Environment name Version number (example)
development environment DEVELOP V1.0.0.DEVELOP
Test environment (advance environment) RELEASE V1.0.0.RELEASE
production environment MASTER V1.0.0

3、 Gitflow best practices

3.1 overall flow chart

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

3.2 examples of best practices

Two students will be moved out here for the next explanation. They are [Gongxing] and [Akang].

3.2.1 remote trunk branch creation

At the beginning of the version (referring to v0.0.0), the code administrator 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 test environment), origin / development (corresponding to development environment) and set protection policies for these three branches. Direct commit and push modification are not allowed for the three branches.

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

The code administrator tags the three initial versions accordingly:(v0.0.0.develop, v0.0.0.release and v0.0.0)

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

3.2.2 local branch creation

After completing the iteration planning meeting (the iteration version number is v0.1.0), Gongxing and Akang claimed two tasks respectively: [development function] Gongxing and [development function 2] Akang.

At this time, Gongxing and Akang will clone the remote warehouse and use it based onorigin/developCreate localdevelop_gxBranching anddevelop_kangBranch.

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

3.2.3 create pr

After they claim the task, they carry out synchronous development. After a period of time, Gongxing takes the lead in completing [development function 1]. Therefore, he needs to submit the current development version to the development environment for self-test and front and rear end joint debugging. However, the [origin / development] is protected and cannot be submitted directly. Therefore, Gongxing needs to apply for PR for the currently developed version, that is, create a pull request, request the code administrator to review the code, and merge it after passing.

The steps involved here are roughly as follows:

1. Push the current local branch to origin to get origin / development_ gx。

2. Create PR: origin / development_ GX merge pull requests into origin / development

3. Wait for the code manager (or students in the group) to conduct code review. If it needs to be modified, directly put forward comments in pr. after modification, the author will directly push it to the remote branch and continue to wait for the code manager to conduct code review.

4. After passing, merge the current commit list into origin / development in the form of squash to obtain the commit of v0.0.1.develop

5. Finally, select Delete origin / development_ Remote branch of GX

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

At this time, Gong Xing has completed the development of the first function, and tag his PR commit on the [origin / development] branch: record this commit as [v0.0.1. Develop]

3.2.4 merge conflict submission version

Soon after, ah Kang also completed the development of [development function 2]. He also needs to submit the code to the origin / development branch for testing and joint debugging. However, at this time, origin / development is different from its base version (the base version is v0.0.0.develop, and the remote version is v0.0.1.develop, one version ahead). If PR is created directly, version merging may not be completed due to code conflict, as shown in the following figure.

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

At this time, Akon needs to pull the origin / development version locally and perform the following operations(it is recommended to directly use the GIT tool provided with the IDE, which will be much more convenient)

//Check whether the remote warehouse has a new version

git fetch origin

//When a new version is found, you need to pull it locally to resolve the conflict and then merge the code

//Staging local modifications

git stash

//Pull remote version

git pull origin/develop

//Fetch local modification

git unstash

//Manual conflict resolution (idea is recommended)

//Submit modification

Git commit – M’1, conflict resolution merge version ‘

Use the conflict resolution tool provided with the IDE, as shown in the figure below

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

Submit modified(be sure to discuss code changes with the author of the conflicting code), you can create PR and wait for the students in the team to conduct code review. After the team members pass, Akon’s modifications can be successfully incorporated into origin / development for joint debugging and testing. A Kang needs to tag the change commit at this time【V0.0.2.DEVELOP】, as shown below:

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

So far, the development work planned by v0.1.0 has been completed.

3.2.5 release of test environment version

After completing the development of version v0.1.0, Gongxing claimed a new task: [test of version v0.1.0]. At this time, Gong Xing, who is developing other functions, needs to stack the local code, merge the code of the origin / development branch with the local code (i.e. git pull origin development operation), and solve the code conflict.

Because you want to publish the code to the origin / release branch for version testing, you need to merge the code on origin / release with the local code (i.e. git pull origin release) and solve the code conflict.

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

After completing git pull origin development and git pull origin release, a new commit version will be formed locally. Gongxing needs to incorporate this commit version into origin / release through PR to complete the release of the test version of the release branch. Therefore, bow students need to repeat3.2.3The PR creation process of step can be released to the test environment only after it is approved by the branch administrator of the release branch.
10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

3.2.6 version marking

After the commit is submitted to the release in the form of PR, the next step is to mark the version. Because the release has completed the development of the version, the current version will be marked as [v0.1.0. Release] on the release branch. Also, on the development branch, the v0.0.2.develop version corresponds to the v0.1.0.release version of release. For the commit on the origin / development branch, the second tag will be marked: [v0.1.0. Develop].

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

Then, the tag processing of the development branch will continue directly from v0.1.0.develop (such as v0.1.1.develop)

3.2.7 thermal 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 and may face the customer directly.

After the version is tested, the test students conduct various tests on the [v0.1.0. Release] version and find that there is a bug in the current version, then the development students should hot fix the bug.

Suppose there is a bug in the test environment, and the bug repair work is still claimed and solved by Gongxing. At this time, Gongxing needs to suspend the development work at hand (GIT stash), then pull the latest version of origin / release branch to the local, and then repair the bug. After the repair, submit the local code to origin / release_ hotfix_ GX branch, conduct PR operation on this branch, and the release administrator will review the code and incorporate it into the release, and record the repair version as [v.0.1.0.1. Release].

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

Of course, because the branch commit has a mapping relationship, the bug that appears in v0.1.0.release must also appear in v0.1.0.develop. So the version of the test environment repaired at this time is still not enough. You need to merge the repair into origin / development. Therefore, Gongxing needs to pull the new version [v0.1.0.1. Release] locally, and then submit the version of origin / development to form [v.0.1.1. Develop]

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

So far, the hot repair process has been completed (the same is true for the hot repair of the master, but it is just the difference of merging the repaired version into release and development according to the actual situation).

3.2.8 production release

After completing the release version testing and bug repair, Gongxing needs to release 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 and add team code review, checklist inspection, release risk control and other operations to ensure the safety of production release.

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

After publishing the origin / master, update the tag of the master to v0.1.0 to complete the publishing of the whole iteration.


Careful students may have found that the three branches of origin / development, origin / release and origin / master are independent of each other in the whole process. Therefore, this workflow belongs to gitflow with three independent branches. If students want to reduce the process, the release branch can be optimized and tested directly on the development branch, (also in line with test driven development)

4、 Two week iterative system and gitflow

4.1 agile two-week iterative system

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

Taking the above figure as an example, there are three vertical functional roles in an agile team:Development, testing, and scrum master (project), we assume that the current iteration isN, the next iteration isN+1, last iteration isN-1

Two week iteration 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 the development of N iteration (current iteration) and hotfix work of n-1 Version (previous version), and carry out unified test every Friday;

· Test:Conduct the development environment test of iteration n (current iteration) and the release environment test of iteration n-1 (last iteration), and complete the test of version n-1 before every Friday;

· Project:Carry out the iteration planning of N + 1 (next iteration) and the iteration release of the previous two iterations (n-2)

In this way, version n-1, version N and version n + 1 can be staggered and orderly (requirements come HHH continuously). Of course, the iterative development time and test time can be changed appropriately (e.g. development: test = 6:4 or 7:3).

The benefits of adopting two-week iteration are:

·Development students have sufficient and flexible time for iterative development, bug repair and requirement understanding

·Test students have enough time to test to ensure the quality of the project (test each function in the development environment, and complete sufficient function tests in the release environment)

·The project has more time to plan the iteration and decomposition of the project, and make more perfect design for specific requirements (crazy planning iteration).

Imagine a scenario: the development completes the development work on the last day of the iteration, and the test is only conducted in the last 2 hours, which is very crazy.

4.2 best practices of biweekly iteration combined with gitflow

Gitflow version management based on two-week iterative system, that is, in the iteration:

·Development: carry out development on origin / development, carry out the development work of step 3.2.4, and work with hotfix of the previous release version;

·The test follows the development to test the development branch and the last release version;

·At the end of the first week, the version will be uniformly distributed to origin / release, and the function test of the current version release environment will be started in the second week;

·On Monday of the third week, the version of the project is released (i.e. to origin / Master)

5、 FAQ

Q1 : Under the microservice architecture, each project has an independent version library. How to achieve uniform version number? Is each microservice prepared with a separate version number or a globally unified version number?

A1 :For each microservice independent version Library under the microservice architecture (or distributed architecture project), it is recommended to prepare the version number globally, that is, the two digit version number of all target release branches and (that is, the global unified iteration code or product number) in the same release window. For microservices that have not been updated, you can publish tags directly on the commit of the original release.

Q2 : The three branch version lines are relatively independent, which is painful for version merging.

A2 :This problem is real. It is recommended to fix the publisher and keep the merge records of release branch, master branch and development branch in the local branch to prevent too many conflicts.

Q3 : For the function published by the target, if there is a risk before the function is published, the branch with risk cannot be released.

A3 :The problem really exists, which can be released in cooperation with the switch configuration.

Q4 : The project is in the stage of rapid development. People have been mentioning PR on the development branch, but no one has done code review.

A4 :You can try to take the tag information in the PR title 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. Everyone wants to mention PR on development, but the last person occupied the three digit version number, so someone needs to dispose of this PR before they can use the next version number, Until the team’s code review habit matures, as shown in the figure below (is the version line of development very clear).

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

Q5 : Allow origin / development, origin / release, and origin / Master branches to merge with each other?

A5 :Not allowed. Branch version merging can only be performed in PR form

Q6 : After using this gitflow, what will the version lines of the three branches look like?

A6 :As shown in the following figure, whether it is the development branch, the release branch and the master branch, the branch always has only one straight line, and there will be no merging between branches, so the version line appears very clean and tidy.

10 years of experience 17 charts take you into the best practices of gitflow enterprise project code version management

Q7 : It seems that the feature branch is not seen in the whole process

A7 :Yes, in this version management, the feature branch has actually sunk into everyone’s local version library and is not directly reflected in the origin library.

Q8 : Can the remote feature branch not be deleted?

A8 :To ensure that the GIT log is clean, it is recommended to delete the individual branch after merging it into the development branch, but it is also possible not to delete the remote feature. You can try to merge the same feature into the release_$ {version} and then execute release_$ {version} – > release pr.

The above is the best practice of project version management: all the contents of gitflow production practice. Welcome to discuss and put forward improvement suggestions in the comment area below!