“Front-end Advancement” — GitLab Flow for code management solutions

preface

As you move up the front end to lead a team on a project, you’re bound to run into the headache of how the code is managed. In general, we use Git to manage code. There are several Git workflows in the industry, and each Git workflow is a code management solution. Only after you are familiar with the process of these several Git workflows can you provide a suitable code management solution to your team.

This article will detail one of these Git workflows, GitLab Flow, which I hope will be helpful to you and feel free to discuss in the comments.

I. Process concept diagram

First, a process concept diagram is presented to introduce GitLab Flow to you.

Ii. Development process

The biggest principle of GitLab Flow is called “upsteam first”, i.e. there is only one master branch, which is “upstream” of all the other branches. Only code changes adopted by upstream branches can be applied to other branches.

Therefore, before developing new features, create a branch for developing new features using the master branch. The name of the branch can be named by the name of the feature. Here, the branch is named feature.

When the function development is completed, use the master branch to merge the feature branch, and delete the feature branch after the merge.

Three, the test process

Deploy the code of the master branch to the test environment, test the bugs, directly fix the bugs on the master branch, and deploy to the test environment for testing after the repair is completed.

Iv. Pre-release process

After the code test of the master branch passes, create a branch with the master branch and name it pre-production. The pre-production branch is the pre-release branch that is deployed to the pre-release environment.

5. Repair the BUG process of pre-release environment

When a BUG occurs in the pre-released code, due to the need to follow the “upstream priority”, the BUG cannot be fixed directly on the pre-production branch. Instead, a BUG fixing branch can be created using the pre-production branch. The name of the branch can be named by the BUG name, and the branch is named fixbug first.

After fixing the BUG, merge the Fixbug branch with the Master branch, and deploy the code of the master branch to the test environment for testing.

If the test fails, continue to fix the BUG on the Fixbug branch, then merge the Fixbug branch with the master branch, and deploy the master branch code to the test environment for testing until the BUG is fixed.

After the BUG is fixed, merge the Fixbug branch with the pre-production branch, and then deploy the code of the pre-production branch to the pre-release environment for testing. If the test passes, the BUG is fixed and the Fixbug branch is deleted. If the test fails, repeat the above steps.

Vi. Formal environment release process

Following the “upstream first” principle, create a branch with the pre-production pre-release branch called Production. The Production branch is the formal branch that is deployed to the formal environment to complete the formal environment release process.

7. Fix the formal environment BUG process

Follow the “upstream first” principle, use the Production branch to create a BUG fix branch, the name of the branch can be named with the BUG name, this branch is first named fixbug.

After the BUG is fixed, after the local test is passed, merge the Fixbug branch with the Master branch and deploy the code of the master branch to the test environment for testing.

If the test fails, continue to fix the BUG on the Fixbug branch, merge the Fixbug branch with the Master branch, and deploy the master branch code to the test environment for testing until the BUG is fixed.

After BUG fixing, we should follow the principle of “upstream first”, so we should first send the code to the pre-release environment for testing, and then release it to the official environment after passing the test.

Merge the Fixbug branch with the pre-production branch. The code from the pre-production branch is then deployed to a pre-release environment for testing.

If the tests pass, merge the Fixbug branches with the Production branch and then deploy to a formal environment to remove the Fixbug branches.

If the test fails, go back to the FixBug branch to fix the BUG and continue until the BUG is fixed.

Viii. Version release process

Releases in GitLab Flow are not in the form of tagging. Instead, create a branch with the master branch. The branch can be named as shown above, such as 2-3-stable, 2-4-stable, etc. Note that the code on the master branch is stable.

If there is a BUG in the code of the version branch, you still need to fix the BUG on the master branch. After the BUG is fixed and passed the test, run the git cherry-pick commitId command on the version branch, where commitId is the commitId submitted for fixing the BUG on the master branch. Merge the bug-fixing code into the release branch and deploy the code to the appropriate environment.