This is a git workflow practice that is gradually adjusted in my personal work practice, in the projects and team collaboration I participated in, and was responsible for, and is suitable for some practical scenarios.

As we all know, in software development, git is currently the most widely used software version management tool. It is efficient, secure and flexible enough. It is very helpful for team collaboration and software management.

A good and suitable branch management solution can better help us manage software version through git.

In the past, git-flow was a very popular branch management solution. For multi-person collaboration, medium and large-scale projects, a relatively satisfactory solution is provided.

But in my past practice, I gradually felt that git-flow was still too complicated for me, although it actually satisfies my software version management of the project. But I believe that it can still be simplified and adjust the branch management strategy to better adapt to actual development work.

Scene

Just imagine, in our actual software development process, iterating over a version of a software, which is normally:

Requirements Review -> Requirements Confirmation -> Development Stage ->
Test environment testing -> Pre-production release verification -> Production environment release verification -> Release completion

From development to release

During this process, if a bug is found in the test environment, it needs to be returned to the development stage for repair. Similarly, problems were found during the pre-production release verification process, and they also needed to return to the development stage to retest and release pre-production after repair.

If there is a problem with the production environment release verification, it is necessary to urgently roll back to the previous version and return to the development stage to repair, test, pre-production verification, and re-production release.

Demand clear or change

Although we have always emphasized that after the version iteration enters development, the requirements for this version should be clear.

However, this is just ideal. In actual processes, you will often encounter requirements changes, even adding new functions, deleting functions, etc. This change is still difficult to control whether it will occur in the development stage or the testing stage.

Maybe we will complain or even complain that such project management that is easy to change needs is terrible and unprofessional. However, this is also a scene that does exist. Even a team that is mature will inevitably encounter this kind of problem.

However, the change in demand does not mean that it must be the above scenario.

Periodic version release, demand pool

Some projects may be relatively mature, or they use different version iteration methods.

Periodic version release means that within a certain fixed cycle, only one version will be released, such as one version will be released every two weeks. So in this mode, what functions are launched in each version and how many functions are launched, actually based on the development progress of each function and after entering the current cycle, The version plan is decided after the clarification.

Clearly divide the product into requirements, establish a demand pool, and specify the expected plan of linear iteration by time for each requirement. What demand features will be launched in the expected future cyclical version release?

In this scenario, it is impossible for us to concentrate all the requirements on a certain branch for development, and it is difficult for the only develop branch to meet all the problems. Development merges and testing.

Developers’ mastery of git

Many times, the degree to which the tool can be used and how helpful it can be to the project is not actually how excellent the tool is, but the team members Whether there is a mature and standardized operation process for the average mastery of tools?

In the early days, I thought that members' mastery of git was quite different. They only needed to explain some operational processes, without restriction and specification.

However, this will also bring potential risks to the project: the main branches may be contaminated by misoperation, multiple functions are directly developed in the same branch, etc.

In order to solve these problems, it is necessary to establish a sufficiently complete set of operating specifications with low complexity, and to control personnel and branches.

Branch management practice

In the above scenarios, a suitable branch management plan has been gradually explored:

• master branch: main branch, official version of code submission record.

You will never make any changes to commit above, and you will only accept merge requests from the release branch, and then type the version tag after the merge.

• release branch: Release branch, used to publish versions to pre-production and production environments, merge them into the master branch after release.

You will never make any changes to commit above, and only merge requests from the prerelease branch are accepted.

• prerelease/* Branch group: Prerelease branch, create a new branch based on the version number.

Only the feature/* branch associated with the current version is merged to merge the requirements completed by the development, enter the version testing stage, and publish to the test environment. No or as few changes as possible to submit any changes on it.

• feature/* branch group: Function development branch (including hotfix), pulls the created branch from the master branch,

Each branch is only for a single business or function, and all changes should be made on the feature branch. Can only be merged into the prerelease branch. After the master is updated, it needs to pull and merge synchronize in time.

flow chart:

It can be seen that the entire solution has only four main branches, and different functional branches to other branches are one-way.

This benefit is simple enough, easy to understand enough, and also ensures a certain degree of flexibility.

The reason for deleting the develop branch is that a single develop branch cannot meet it well. The develop branch caused by the change of requirements is invalid. Choose to use the prerelease branch group as a substitute, and you can flexibly create branches based on version planning. Even if there is a change in demand, you can flexibly discard it directly. For the currently created branch, create a new prerelease branch and merge the code from the feature branch again.

It is also because the function branch is not merged immediately after development, but is merged according to the iteration plan. The expected online function, namely prerelease.

From the behavior of the branch, the master branch and the release branch seem to be able to keep only one in simplification. But here is to consider if there is a rollback operation, All are done on the master branch, so the operation records of the master branch don't seem to be clean and concise enough, and puts publishing, rollback and other strategies on the release branch , while master only retains a clean version history, it will be more friendly and easy to maintain.

In this solution, it is best to cooperate with the permission control of the git branch to protect the master branch and release branch to ensure that these two branches only accept the corresponding ones from the corresponding ones A merge request for the branch.

When merging the branch, selecting merge or rebase, this requires consideration of the requirements for commit records. If you need to ensure that all submission records are traceable, it is recommended to use merge. If you want the submission records to be linear and tidy, it is recommended to use rebase.

At the same time, the feature branch is merged into the prerelease branch, preferably through the operation mode of pull requests, and before entering the test phase, it is necessary to accept other ones from the test Useful code review for developers with review permissions.

Description

This practical plan is only a practical plan that I summarized in my work practice in the past and obtained through more than 2 years of verification and adjustment within the team. It is suitable for the team at that time.

Whether it fits with your team or the one you are in needs to be reconsidered.

Branch management plans need to be considered based on actual situations, including the number of team members, product size, etc.

There is no best solution, only the one that suits you.