background

From the beginning of svn to the later contact with git, I have dealt with git a lot now. I suddenly felt that I could share some branch management methods used in the project, hoping to help everyone.

Branch introduction

Nowadays, git is rarely used for a single branch, but usually for multiple branches. Next, I will make some introductions based on the branches used in my latest project.

master:

• The master branch code can only be merged with the release branch, and the merge action can only be performed by specific administrators.
• The master branch is a protected branch. Developers cannot directly push to the master branch of the remote warehouse.

release:

• Naming rules: release/*, “*” generally identifies the project, issue, date, etc.
• This branch is a protected branch. Developers cannot push directly. Generally, a certain person is selected for overall control and push.
• This branch is the production branch
• This branch is pulled based on the master branch every time

dev

• This is a development branch, and everyone can develop based on this branch.
• The code requirement for this branch is that it is no problem to start locally and does not affect other people’s code.

hotfix

• This branch is generally used as an emergency repair branch. This branch is needed after problems are discovered after the current release is released.
• This branch is generally pulled from the current release branch
• After this branch is developed, it needs to be merged into the release branch and the dev branch.

feat

• This branch is generally a long-term feature that requires continuous development or adjustment.
• This branch can also be created based on release or stable dev.
• Generally, after development, it needs to be merged into the dev branch.

Branch usage

The above is a brief introduction to several branches. Next, I will sort out some scenarios for the above branches to facilitate everyone’s understanding.

First, create a release branch from master as the branch for this production, and then pull a dev branch from master to facilitate development. I named the dev branch: dev/soe, and then I developed on this branch, and so did everyone else. so.

Then when I finish developing a certain task, there is another task. However, this task needs to be done, but whether it will be put into production this time is yet to be determined, so in order not to affect everyone’s development, I cannot develop it in the dev branch. At this time, I created a feat branch based on the currently stable dev branch, called: feat/sonar, mainly to fix some scanning problems. During this period, if I receive another development task, I can still Switching to dev for development has no effect.

When the development work is completed and tested based on the dev branch, and I feel that there is no problem, I will merge the code from the dev branch into the release.

After the release is put into production, if there are no problems after the business verification, then a dedicated person can merge the release into the master. If a problem is found, then a hotfix branch needs to be created based on the release at this time, and the developer can solve the problem in this branch. After the repair is completed and tested, merge it into the release branch and the sit branch. Then use the release branch for production.

Summarize

The above is my use of branches in the project. I think the use of branches depends on the needs of the team and the project. It does not have to be determined. If some projects do not require release and production, then there is no need to use hotfix and release directly. It’s not a bad idea to merge it after modification, so how do you use it in the project? You can discuss and share together in the comment area.