There is no silver bullet

With git version control tools all the rage today, git-based workflows are standard, and as developers we’ve all been exposed to them. There are three main git flow, Github Flow and Gitlab flow in the market now. As for the reason why I suddenly study these flows, the main reason is that WHEN I was writing my own small project, I strongly set git flow mode. I felt that the flow was too long, so I wanted to see if other flows could alleviate this situation.

git flow

Git Flow is one of the earliest and most complete workflows proposed. This model was put forward as early as 2010, and it has been used for more than 10 years now (2021), which shows its strong completeness. To get a feel for Git Flow, take a closer look at the following figure before we start analyzing it.

Git flow branches are divided into two types: main branch and temporary branch. The main branch is long-term, and the temporary branch is mainly used for development work, and can be deleted after the merge.

Main branches

The following two branches are permanent in the project lifecycle.

  • master
  • develop

Master is the master branch on which releases are made, but this branch is not used as a daily development branch.

The Develop branch is where all of our development work is done.

Temporary branch

Temporary branches mainly have the following three branches.

Hotfixes Branch Feature Branch Release Branch Hotfixes BranchCopy the code

Git Flow only defines these three branches, but in real projects we need more types of branches to support our development, such as test file changes, document changes and so on. We can increase the type of branch we need according to the needs of the project.

Feature Branch

This branch is used to merge new functionality into the Develop branch.

Release Branch

Release Branch is a Release branch that is removed from the Develop branch at some point after it has stabilized or is ready for Release. This branch is used for version updates, pre-release checks, and other things like that. If there are bugs, fix them in the Release branch. Merge into Master and Develop, respectively.

HotFix Branch

When a bug needs to be fixed urgently, a hotfix branch needs to be set up to fix it. The Hotfix branch is a feature branch. The hotfix branch is a feature branch. The hotfix branch is a feature branch.

Also, if there is a release branch when Hoxfix is done, you need to merge hotfix into the Release branch, merge hotfix into the Develop branch before release, and release will be released as usual.

Advantages and disadvantages

Pros: Git Flow is clear and controllable, with every flow in development considered, making it ideal for multi-release projects

Disadvantages: too complex, cumbersome process

Github Flow

Github Flow is a simplified Git workflow that works well with continuous delivery. In Github flow, there is only one long-term branch, the master branch.

process

1. Pull new branches from master branch 2. Launch PR for discussion and review after development 3. After the discussion and review is approved, deploy for final test (this can be done automatically with some CD tools) 4. Merge to master branchCopy the code

Advantages and disadvantages

Pros: Simple and great for “continuous publishing”

Disadvantages: Release time is not controllable, can cause online and main branch inconsistency in case of release window

gitlab flow

The core of Gitlab flow is upstream first, and there is only one master branch. Gitlab will have some changes for different situations, but will not deviate from this principle. Gitlab provides two common situations, namely continuous release and version release. We will understand GitLab Flow in the following two situations.

Sustained release

Many times, we have a release window that is not always available, and in this case the limitations of Github Flow are exposed. It is more suitable to use GitLab Flow at this time. The flow of GitLab Flow is that all development branches merge into the Master branch and then cherry pick to the Production branch when needed for release. The same goes for bug fixes. If there is a pre-production environment, you can pull a pre-production branch as the upstream of production, and the master as the upstream of pre-production, which is still the principle of upstream to downstream. Please refer to the following flow chart for the process.

release

For a “release” project, each release node pulls a branch from the master as a stable release, and only serious bugs are incorporated into the released branch after the release.

conclusion

Once again, “there is no silver bullet”, we just need to choose a Git workflow that matches the requirements. Even if there are special scenarios, we just need to adjust them accordingly.

Refer to the link

Nvie.com/posts/a-suc…

Docs.gitlab.com/ee/topics/g…

Guides.github.com/introductio…