Abstract: Let’s talk about the workflow in Git — branch strategy.

Git Workflow: GitFlow, GitHubFlow, and GitLabFlow

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).

Before I visited an enterprise, the development team in the enterprise used Git to manage daily development work, and I encountered a problem during 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 branch strategy. This article will briefly talk about the workflow in Git — branch strategy.

Common branching strategy

The branch strategy mentioned above is confusing, and it is not mainstream. Using the mainstream branch strategy will avoid the above problems.

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

Git Flow

GitFlow is the earliest of the three branching strategies.

GitFlow typically contains five types of branches: Master, Develop, Feature, Release, and Hotfix.

  • Master branch: A trunk branch, also a release branch, that contains code that can be deployed to production, but is generally only allowed to be merged by other branches and not directly submitted to the Master branch (for production).

  • Develop branch: A development branch that integrates testing of the latest development effort and contains the code to be released to the next Release (corresponding to the development environment).

  • Feature branch: A Feature branch, usually pulled from the Develop branch, where each new Feature is developed for developers to submit code and test themselves. After the test is complete, the Feature branch’s code is merged into the Develop branch and the next Release is released.

  • Release branch: A Release branch that is created based on the Develop branch when a new Release is released and merged into the Master and Develop branches (corresponding to the integration test environment).

  • Hot fix branch: Hot fix branch, a temporary branch created when a new Bug is found in production that is merged into the Master and Develop branches once the problem is verified.

The usual development process for new features is as follows:

A Feature branch is pulled from the Develop branch, and the development team develops new features on the Feature branch. After development, merge the Feature branch into the Develop branch and verify the development environment. After verifying the development environment, pull a Release branch from the Develop branch to the test environment for SIT/UAT tests. Once the tests are clear, merge the Develop branch into the Master branch and deploy the Master branch code directly to production when the release is ready.

Please refer to the picture below:

The advantage of GitFlow is that each branch is clearly defined. If the project code is managed strictly according to GitFlow, it is difficult to have code confusion. Its disadvantages are: if there are too many feature branches, it is easy to cause code conflicts, thus increasing the cost of integration; Since multiple branches are involved in each commit, GitFlow is also not suitable for projects with high commit frequency.

Use Huawei Cloud DevCloud to achieve Git Flow

1. Create a branch

The code hosting function of Huawei Cloud DevCloud supports end-to-end GitFlow. We can create branches in the code repository, as shown in the figure. Currently, there are major branches: Master branch, Develop branch, and two feature branches: Feature-bill and feature-score branches.

2. Create pipelining for branches

The pipeline-line function needs to be configured in the pipeline-line function of Huawei Cloud DevCloud. Create a pipeline-line based on the feature-Bill branch.

The construction and deployment tasks are configured in the pipeline to facilitate the verification of the construction and deployment of feature-Bill branch code (such tasks as construction and deployment need to be created under the corresponding module in advance).

3.Feature submission code and verification

After the feature-Bill branch is developed, the submitted code can trigger the pipeline for verification.

4. Close the code to the Develop branch for validation

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 is triggered for validation because the code in the Develop branch changes.

Once the Develop branch is validated, the team can pull the Release branch, 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. When the test environment is verified, the code is merged into the Master branch, and the Master pipeline is created and started to upgrade and verify the production environment.

GitHubFlow

GitHubFlow is named after GitHub and is derived from the work practices of the GitHub team. When code is hosted on GitHub, you need to use GitHubFlow. GitHubFlow has fewer branches than GitFlow.

GitHubFlow usually has only one fixed Master branch, and the Master branch in GitHubFlow is usually protected so that only people with certain privileges can 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 the new branch; After the function is developed, the developer will create a PullRequest (PR for short) and notify the source warehouse developer to review the code. After confirmation, the source warehouse developer will merge the code into the Master branch.

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

The advantage of GitHubFlow is that it is relatively simple compared to GitFlow. The disadvantage of GitHubFlow is that there is only one Master branch. If the code is merged, the Master branch cannot be released immediately due to some factors, the final release version and plan will be different.

GitLabFlow

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

GitLabFlow supports the branch strategy of GitFlow as well as GitHubFlow’s “Pull Request” (known in GitLabFlow as a “Merge Request”).

Compared with GitHubFlow, 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 stipulates that the code must be developed from upstream to downstream, that is, when new functions or bugs are fixed, the code of the feature branch must be integrated into the Master branch first, and then it can be integrated into the pre-production environment from the Master branch. Finally, pre-production is merged into Production.

MergeRequest in GitLabFlow is a request to merge one branch into another. MergeRequest allows comparisons between merged and merged branches, as well as code Review.

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

1. Set the protection branch

The repository administrator selects “Protected branch Management” from “Settings” for code hosting, and then sets the Master (or Develop) branch to be protected. Normal developers are not allowed to submit code to the Master branch, nor are they allowed to merge code. Only the warehouse administrator can submit or merge code to the Master branch.

2. Create a merge request

In the merge Request section of the repository, create a merge request to merge the feature-Bill branch into the Develop branch.

And specify reviewers and personnel to perform the plug in operation.

3.Review the code and pass the merge request

After receiving the merge request, relevant personnel can compare the changes before and after the file through “File Change” and perform the merge operation after confirming the correctness. If there is a conflict, the conflict can be resolved online or offline.

In addition to performing merges, code can also be reviewed and scored to make recommendations for merging feature-bill branches.

conclusion

There is no best branch strategy, only the branch strategy most suitable 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 to follow, the first time to learn about Huawei cloud fresh technology ~