“This article has participated in the good article call order activity, click to see: back end, big front end double track submission, 20,000 yuan prize pool for you to challenge!”

preface

Git-flow is a Branch model of Git proposed by Vincent Driessen in 2010. During this decade, Git-flow has become so popular among many software teams that it has become regarded as something of a standard. However, Vincent Driessen recently updated his famous 10 year old post, A Successful Git Profile Model, to the effect that the Git-flow is not appropriate for today’s continuous delivery software engineering approaches, and recommends simpler models such as the Github Flow

Even the author of Git-flow admits that git-flow is no longer suitable for continuous delivery, so we need to take a closer look at it before we fall into the trap. This article covers the following topics: 1. Introduction to Git-flow 2. Why is Git-flow not suitable for continuous delivery? 3. Introduction to Github Flow

1. Git-flowWhat is?

Git-flowIs made up ofVincent DriessenOne that was proposed in 2010GitBranch model, its structure diagram is shown below, I believe you have seen



Git-flowIt mainly includes the following branches

  • masterIs a long-term branch that is generally used to manage external releases, eachcommitFor atagThat is, a release version
  • developIs a long-term branch that is typically used as a daily development summary, the development version of the code
  • featureA short-term branch, usually used for the development of a new feature
  • hotfixA short-term branch that appears after a releasebugNeed to create a branch, proceedbugRepair.
  • releaseA short branch, usually used before a releasemasterBefore branching), you need to test the pre-release.releaseAfter the branch has been tested, the tests confirm acceptance and will be merged intodevelop 和 master

1.1 Git-flowThe working process

The general working process is as follows:

  • 1. In the dailydevelopThe development of
  • 2. If there are large functions or other requirements, then open new branches:feature/xxxDo, and package and test on this branch.
  • 3. On seal day, merge the requirements for the release to go live intodevelopAnd then we’ll open a new branchThe release/version number(e.g.,The release / 1.0.1),developMerge into the branch.
  • 4. Gray level, inThe releases/version numberFix bugs on the branch, package and release, and back in when the release is completemasterwithdevelopbranch
  • 5. If the cable problem is found after the full release, the correspondingmasterNew branch on branchHotfix /{version number}To fix and upgrade the version number, after the fix is complete, then willhotfixIncorporated into themasterAnd will be merged intodevelop

2. WhyGit-flowNot for continuous delivery?

In those 10 years, Git itself has taken the world by storm, and the most popular type of software developed with Git is moving more toward Web applications — at least in my filter bubble. Web applications are typically delivered continuously, not rolled back, and you don’t have to support multiple versions of software running simultaneously.

As Vincent Driessen puts it. Git-flow describes how the feature branch, release branch, master or Develop branch, and hotfix branch are related to each other. This approach works well for packaged software downloaded by users, such as libraries and desktop applications.

However, for many Web applications, Git-flow is an overkill. Sometimes, there isn’t enough difference between your Develop and release branches to make the distinction worthwhile. Alternatively, your HotFix branch and your Feature branch might have the same workflow. In this case, Vincent Driessen recommends the Github Flow branching model

The main advantage of Git-flow is that it has a clear structure, and the tasks of each branch are clearly divided. The disadvantage of Git-flow, of course, is that it is a bit complicated and requires maintaining two long-term branches at the same time. Most tools use master as the default branch, but development takes place in the Develop branch, which can be annoying to have to switch branches frequently. The bigger problem is that this pattern is based on “release releases”, where the goal is to produce a new release over time. Many web projects, however, are “continuous releases,” deploying as soon as the code changes. At this point, there is little difference between the Master and Develop branches and there is no need to maintain two permanent branches

2.1 Git-fowWhen the extra complexity is worth it

, of course, whether or not to use Git – flow depends on your business complexity, sometimes use Git – flow is necessary, mainly when you need to maintain multiple versions at the same time, suitable is the need for multiple versions coexist “scene The so-called “multi-version coexist”, that is, the development team to maintain multiple have customers to use the version at the same time, for the traditional software, For example, I developed a new operating system called Doors, sold V1 first, sold 10 million copies, and then watched as I developed V2 on top of V1, but the customers kept bugging V1, which had to be fixed in subsequent patches of V1 as well as in V2, and by the time V2 sold another 20 million copies and started developing V3, V1 still has customers, I have to maintain V1, V2, V3 three more versions to support.

Many people may have doubts about git-Flow’s support for multiple releases at once, since Develop only works on a single release for continuous delivery. Can support multiple versions at the same time, in the interest of students can be reference: mindsers. Blog/post/severa…

3.Github flowintroduce



Github flowIt has only one long-term branch, which ismaster, so it’s very simple to use.

  • Step 1: According to the needs, frommasterPull a new branch without distinguishing between a feature branch or a patch branch.
  • Step 2: When the new branch is developed or needs to be discussed, go tomasterTo launch apull request(hereinafter referred to asPR).
  • Step 3:Pull RequestIt’s both a notification to bring your request to attention and a conversational mechanism to review and discuss your code together. You can also commit code over and over during the conversation
  • Step 4: Deployment process: When the project leader agrees that the new feature is ready for release and the code is approved. But you still need to test the code before you merge it. So want tofeatureThe branching code is deployed to the test environment for testing
  • Step 5: YoursPull RequestBe accepted intomasterWhen you redeploy to the production environment, the original branch that you pulled out is deleted.
  • Step 6: Fix the formal environmentbugProcess:masterBranch off oneHotFixBranch, initiated by the same process abovePRMerger then

3.1 Github flowThe advantages of

The great thing about Github Flow is that it’s simple, and it’s arguably the most appropriate process for “continuous release” products.

3.2 Github flowThe disadvantages of the

Its problem is also its assumption that updates to the Master branch are consistent with the release of the product. In other words, the latest code for the master branch defaults to the current online code. However, sometimes this is not the case. Just because code is merged into the Master branch does not mean it will be released immediately. For example, once an APP is submitted for review in the Apple Store, it takes some time before it hits the shelves. At this point, if new code is committed, the master branch will be inconsistent with the release. Another example is that some companies have release Windows that can only be released at a specified time, which can also cause the online version to lag behind the Master branch. In this case, it’s not enough just to have a master branch. Usually, you will have to create a production branch in addition to the Master branch to track the online version.

At the same time, I have a question about Github flow. After merging into the Master branch, it will be deployed to the production environment, but won’t the code after merging cause conflicts? Don’t merge conflicts need to be retested? If there is someone in the comment section who knows this, you can clarify it

Github Flow is relatively simple to use, but in many companies’ business development process, there are generally development, test, pre-release, production environment, without strong tools to support, I think it is difficult to use this simple mode to achieve management. It seems that this model is particularly suited to small teams, with fewer people and fewer needs, and it is easier to manage branches this way.

4.Gitlab flowintroduce

Gitlab Flow is a synthesis of Git-flow and Github Flow. It takes the best of both worlds, the flexibility to adapt to different development environments and the simplicity and convenience of having a single main branch. It’s recommended by Gitlab.com. The biggest principle of Gitlab Flow is called “upsteam First” — there is only one master branch, which is “upstream” of all the other branches. Only code changes adopted by the upstream branch can be applied to other branches. Gitlab Flow is divided into continuous releases and version releases to accommodate different release types

4.1 Continuous Release



For “continuous release” projects, it recommends the followingmasterCreate a different environment branch in addition to the branch.

For example, the “development environment” branch ismaster, the preemptive environment branch ispre-production, the “production environment” branch isproduction.

The development branch is “upstream” of the pre-issued branch, which in turn is “upstream” of the production branch. Code changes must evolve from “upstream” to “downstream”. For example, if there is a bug in the production environment, you should create a new branch of the function, first merge it into master, and then cherry pick to pre-production, and then enter production.

Only in an emergency is it allowed to skip upstream and merge directly into a downstream branch.

4.2 Release



For “release” projects, the recommended practice is that every stable release is made frommasterA branch pulls out a branch, for example2-3-stable,2-4-stableAnd so on.

After that, there is only repairbugIs allowed to merge code into these branches, and the minor version number is updated at this point.

4.3 Gitlab flowThe development process

For Android development, we typically use release releases, so our development workflow using Gitlab Flow is

  • 1. New iteration starts with all developers from the trunkmasterPull personal branch development features, branch naming conventionsfeature-name
  • 2. After completion of development, before the end of the iteration, plug inmasterbranch
  • 3.masterBranches are merged automaticallycicdtodevThe environment
  • 4. After passing the development self-test, frommasterPull the branch to release,release-$version, deploy the branch to the test environment for testing
  • 5. Measurebug, through therelease-$versioPull out the branch to repair, and when the repair is complete, close in againrelease-$versio
  • 6. The official release version, if there isbug, according to 5
  • 7. When the release is stable, it willrelease-$versioAnti-amalgamation main stemmasterbranch

Note that, according to the Github Flow specification, step 5 if you detect a bug, you should fix it on master and then cherry-pick through releases, but it’s too cumbersome to do so. Fixing bugs directly in the RELEASES branch and then reverting to the Master branch should be a simple and acceptable practice

conclusion

In short, as Vincent Driessen says, always remember that there is no magic bullet. Consider your own background. Don’t hate. Decide for yourself.

Git-flow is suitable for large teams with multiple iterations of the development process. Github-flow is suitable for small and medium-sized teams with continuous integration of the development process. Gitlab-flow is suitable for between the two, supporting both continuous release and version release

After all, there are no silver bullets in software engineering. It’s up to you to compare and choose your own workflow for your own project

The resources

What do you think about Git Flow inventors who say it doesn’t work for continuous delivery? Git Development Workflow: Git Flow and GitHub Flow Git Workflow GitLab Flow best practices for high-performance teams

Further reading

Git workflow of some big factories, interested students can understand under Ali, how do we manage the code branch? My Git Work Flow