Abstract:Talk about workflow in Git — branching strategies.

This article is from the Huawei Cloud community “Git workflow common three branching strategies: Gitflow, Gitubflow and Gitlabflow”, the original author: agile little wisdom.

preface

Version control system is to point to the program code in the software development process, configuration files, documents such as the change of management system, it can help the team better communication and collaboration, thereby better delivery, the version of common control system can be divided into centralized version control system (such as SVN) and distributed version control system (Git).

I visited an enterprise before, and the development team in the enterprise used Git to manage daily development work. There was a problem in the development process: Branching strategy use is chaotic, the original development team branches from the trunk to pull out a feature branch, but after the completion of the new features, this feature branch without closing the trunk branches, but as the next development backbone branches, to pull out a new feature branch, lead to the trunk has been useless, team without a stable branch.

This problem is largely due to the team’s lack of understanding of the branching strategy. This article will briefly discuss the workflow in Git — branching strategy.

Common branching strategies

The branching strategy mentioned above is confusing, and it is not mainstream. The branching strategy used by the team can avoid these problems.

There are three common branching strategies: GitFlow, GitubFlow, and GitLabFlow.

Git Flow

GitFlow is the earliest of the three branching strategies.

Gitflows typically contain five types of branches: the Master, Develop, Feature, Release, and Hotfix branches.

  • Master branch: The trunk branch, which is also the official release branch, contains code that can be deployed to a production environment. Generally, only other branches are allowed to merge code into the Master branch and not to commit code directly to the Master branch (corresponding to the production environment).
  • Develop branch: The development branch that integrates and tests the latest integrated development and contains the code to be released to the next Release (corresponding to the development environment).
  • Feature branch: The Feature branch, usually pulled from the Develop branch, is used for each new Feature to be developed and for developers to submit code and self-test. After the self-test is complete, the code from the Feature branch is merged into the Develop branch to proceed to the next Release.
  • Release branches: Release branches that are created based on the Develop branch when a new Release is released and merged into the Master and Develop branches (for the integrated test environment) when the Release is complete.
  • Hot fix branch: Hot fix branch, a temporary branch created when a new Bug is found in production, and merged into the Master and Develop branches when the problem is verified.

In general, the development process for new features is as follows:

Pull a Feature branch from the Develop branch and the development team will Develop new features on the Feature branch. After the development is completed, integrate the Feature branch into the Develop branch and verify the development environment; The development environment verification is completed, and a Release branch is pulled from the Develop branch to the test environment for SIT/UAT testing. After the tests are fine, you can combine the Develop branch into the Master branch, and when you’re ready to release, you can deploy the Master branch code directly into production.

Please refer to the following figure:

The advantage of Gitflow is that each branch is clearly defined, and it is very difficult to get messy when managing project code strictly in Gitflow. The disadvantage is that if there are too many branching features, it is easy to cause code conflicts, which increases the cost of integration. Because each commit involves multiple branches, GitFlow is also too unsuitable for projects with high commit frequency.

Git Flow is realized by using Huawei DevCloud

1. Create a branch

The code hosting function of Huawei Cloud DevCloud supports end-to-end Gitflow. We can create new branches in the code warehouse, as shown in the figure. At present, there are main branches: Master branch and Develop branch, and two Feature branches: feature-bill branch and feature-score branch.

2. Create a pipeline for branches

Pipelining function needs to be configured in the pipelining function of Huawei Cloud DevCloud, and a new pipelining is created based on the “feature-bill” branch.

Configure the build and deployment tasks in the pipeline to facilitate the verification of the build and deployment of the feature-bill branch code (the build and deployment tasks need to be created in advance under the corresponding module).

3. Submit the code of the Feature and verify it

After the feature-bill branch is developed, the submission of the code triggers the pipeline for verification.

4. Check your code in the Develop branch

Similarly, you need to create a pipeline for the Develop branch. When the feature-bill branch is merged into the Develop branch using the merge command, the pipeline will also be triggered for validation due to code changes in the Develop branch.

Once the Develop branch has been validated, the team can pull the Release branch and create and start the pipeline of the Release branch for test environment validation. If defects are found, they can be modified and verified directly in the Release branch. After the test environment validation is passed, the code is merged into the Master branch, and the Master pipeline is created and started to upgrade and validate the production environment.

GitHubFlow

The name GitHubFlow is also related to GitHub, which is derived from the GitHub team’s work practices. When code is hosted on GitHub, you need to use GitHubFlow. Compared to GitFlow, GitubFlow does not have as many branches.

Only one Master branch in a GitHubFlow is usually fixed, and the Master branch in a GitHubFlow is usually protected, with only certain permissions allowed to merge code into the Master branch.

In GitHubFlow, new feature development or Bug fixing requires pulling a new branch from the Master branch and committing code on that branch; After the function development is completed, the developer creates a Pull Request (PR for short) and informs the source warehouse developer to review the code modification. After the confirmation, the source warehouse developer will merge the code into the Master branch.

Many people may ask why commit code is usually a commit or push, and pull code is a pull, so why submit code in GitHubFlow is a “pull Request”. Because PR in GitHubFlow is telling other people to go to your code base and pull the code locally, and then they do the final commit, use “pull” instead of “push”.

The advantage of GitubFlow is that it is relatively simple compared to GitFlow, but the disadvantage is that there is only one Master branch. If the code is merged and the Master branch is not released immediately for some reason, the final release and the planned release will be different.

GitLabFlow

GitLabFlow, the practice recommended by the open source tool GitLab, is the latest to appear.

GitLabFlow supports the branching strategy of GitFlow, as well as GitubFlow’s “Pull Request” (known as the “Merge Request” in GitLabFlow).

Compared with GitLabFlow, GitLabFlow adds the management of pre-production environment and Production environment, that is, the Master branch corresponds to the branch of development environment, and the pre-production and Production environment are managed by other branches (such as pre-production and Production). In this case, the Master branch is upstream of the pre-production branch, which is upstream of the Production branch. GitLabflow specifies that code must be developed from upstream to downstream. In other words, when new functions or Bug fixes are tested correctly, the code of feature branch must be merged into Master branch before it can be merged into pre-production environment from Master branch. Finally, the pre-production was combined into Production.

The Merge Request in GitLabFlow is a Request to Merge a branch into another branch. Through the Merge Request, the differences between the merged branch and the merged branch can be compared, and the code can be reviewed.

Huawei cloud DevCloud also supports GitLabFlow’s merge requests to protect trunk branches from interference.

1. Set up the protection branch

The repository manager, in the Code Managering Settings, select Protected Branch Management, and then set the Master (or Develop) branch to the Protected Branch. Normal developers are not allowed to commit code to the Master branch, nor are they allowed to merge code. Only the repository manager can commit code to the Master branch or merge code into the Master branch.

2. Create merge request

In the “Merge Request” section of the code repository, create a merge request that the feature-bill branch be merged into the Develop branch.

And designate the reviewers and the people who perform the merge operation.

3.Review the code and pass the merge request

After receiving the merger request, the relevant personnel can compare the changes before and after the document through the “file changes”. After confirming that there is no mistake, the merging operation can be carried out. If there is any conflict, the conflict can be solved online or offline.

In addition to performing merge operations, you can also comment and score the code and suggest merging of feature-bill branches.

conclusion

There is no best branch strategy, only the most suitable branch strategy for the team. The advantages and disadvantages of each branch strategy have been listed above. You can choose the appropriate branch strategy for development according to the situation of the team.

Click on the attention, the first time to understand Huawei cloud fresh technology ~