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…