1 Introduction to Git Flow

As we all know, branching in Git is much more convenient than SVN, and it is highly recommended to use branching for development. The master branch is the master branch, which ensures a stable version of the application. Develop is the development branch, where almost all the functionality and bug fixes are done. Then merge back to master.

But the situation is not so simple. Sometimes when we are working on a feature and the application suddenly has a bug that needs to be fixed, we cut back to the Master branch and create a Hotfix branch based on it. Sometimes we are working on one feature and need to stop to work on another. And when all of these issues come up, publishing can be tricky.

That said, Git Branch is powerful, but there is no set of models that tell us how to use these branches in development. The Git Flow model is designed to show us how to use Git branches better.

Master Develop feature release hotfix support git-flow is a code branch management model based on git branch and git tag. Master corresponds to launch, Develop corresponds to development, and several others appear in different situations. Through encapsulation, Git-flow hides relatively complex commands such as Git branch (which is complex, especially in the case of multiple branches) and provides a simple and standardized solution to code branch management.

In simple terms, Git Flow divides branch into two main branches and three temporary auxiliary branches:

Main branches

Master: always in the production-ready state **;

The latest state of development

Auxiliary branch

Feature: Branch to develop new features, based on develop, merge back to Develop;

Release: a branch that prepares a version for release, used to fix bugs. Merge back to develop and master based on develop;

Hotfix: Fixes issues on the master that must be released immediately before the release. Merge back to master and develop based on master;

2 Git Flow

2.1 Git Flow installation construction

Install git – flow:

➜ brew install git - flowCopy the code

Build git-flow model in a new directory:

➜ git flow init
Copy the code

Then it will ask you a series of questions. Fuck! Try to use its default values:

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Copy the code

Or build from an existing repository:

➜ git flow init
Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Copy the code

A Git-flow branch model is initialized.

2.2 Scenario 1: New function development, code F1

1. Enable branch development of new functions based on Develop

   After completing the previous build, the current branch becomes Develop. Any development must start with Develop:

   ➜ git flow feature start f1
   Copy the code

   Git-flow creates a new branch feature/f1 from the Develop branch and automatically switches under it. F1 functionality can then be developed, with multiple COMMIT operations in between.

   Push an F1 branch to a remote server to work with other developers:

   ➜ git flow feature publish f1
   
   或者
   
   ➜ git push origin feature/f1
   Copy the code

2. Complete the function development, end the new function branch and delete:

   ➜ git flow feature finish f1
   Copy the code

   The feature/f1 branch will be merged into Develop, then delete the branch and switch back to Develop. At this point, the new feature development scenario is complete. In f1 feature development, it is ok if F1 is not completed and f2 is to be started.

2.3 Scenario 2: Release online (code: 0.1

1. Develop and publish branches based on Develop

   ➜ git flow release start 0.1
   Switched to a new branch 'release / 0.1'
   
   Summary of actions:
   - A new branch 'release / 0.1' was created, based on 'develop'
   - You are now on branch 'release / 0.1'
   
   Follow-up actions:
   - Bump the version number now!
   - Start committing last-minute fixes in preparing your release
   - When done, run:
   
   git flow release finish '0.1'
   Copy the code

2. Git-flow creates a new branch release/0.1 from the Develop branch and switches to that branch. After the completion of the:

   ➜ git flow release finish 0.1
   Switched to branch 'master'
   Merge made by the 'recursive' strategy.
    f1      |    1 +
    version |    1 +
    2 files changed, 2 insertions(+)
    create mode 100644 f1
    create mode 100644 version
   Switched to branch 'develop'
   Merge made by the 'recursive'strategy. version | 1 + 1 file changed, 1 Insertion (+) CREATE mode 100644 version Deleted Branch Release /0.1 (was D77DF80). Summary of Actions: - Latest objects have been fetched from'origin'
   - Release branch has been merged into 'master'
   - The release was tagged '0.1'
   - Release branch has been back-merged into 'develop'
   - Release branch 'release / 0.1' has been deleted
   Copy the code

3. Git -flow will then go to master Develop and merge the changes in release/0.1, then add a git tag of 0.1 to the release.

   ➜ git:(master) git tag
   0.1
   0.2
   Copy the code

2.3 Scenario 3: Urgent bug fix, code bug1

1. Open the hot repair branch based on master

   ➜ git flow hotfix start bug1
   Switched to a new branch 'hotfix/bug1'
   
   Summary of actions:
   - A new branch 'hotfix/bug1' was created, based on 'master'
   - You are now on branch 'hotfix/bug1'
   
   Follow-up actions:
   - Bump the version number now!
   - Start committing your hot fixes
   - When done, run:
   
   git flow hotfix finish 'bug1'
   Copy the code

2. Git-flow creates a new branch hotfix/bug1 from the master branch and switches to that branch. The next thing to do is fix the bug, and when done:

   ➜ git flow hotfix finish bug1
   Switched to branch 'master'
   Merge made by the 'recursive' strategy.
    f1 |    2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)
   Switched to branch 'develop'
   Merge made by the 'recursive' strategy.
    f1 |    2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)
   Deleted branch hotfix/bug1 (was aa3ca2e).
   
   Summary of actions:
   - Latest objects have been fetched from 'origin'
   - Hotfix branch has been merged into 'master'
   - The hotfix was tagged 'bug1'
   - Hotfix branch has been back-merged into 'develop'
   - Hotfix branch 'hotfix/bug1' has been deleted
   Copy the code

   Git-flow switches to the Master Develop branch and merges hotfix/bug1, then drops the hotfix/bug1. At this point, hotfix is done.

   Git-flow feature releases are created from the Develop branch and hotfix support is created from the Master branch.

A kind of classical branch management specification

As shown above:

1. The most stable code is stored on the master branch (equivalent to the trunk branch of SVN). We do not submit code directly on the master branch. We can only merge code on the master branch, for example, merge code from other branches into the master branch.

2. Our daily development code needs to pull a Develop branch from the Master branch, which everyone can access, but we don’t commit code directly to the Develop branch. Code is merged into the Develop branch from other branches.

3. When we need to develop a feature, we need to pull a feature branch from the Develop branch, such as feature-1 and feature-2, and develop the feature on those branches in parallel.

4. After a feature is developed and we decide that we need to release it, we need to pull a release branch from the Develop branch, such as release-1.0.0, and merge the features from the relevant feature branch into the Release branch. The test environment is then deployed against the Release branch, where the test engineer does functional testing and the development engineer fixes bugs.

5. When the test engineer cannot find any bugs, we can deploy the release branch to the pre-release environment. After verification again, there are no bugs, and then we can deploy the Release branch to the production environment.

6. Once live, merge the code on the Release branch into both the Develop and Master branches, and tag the master branch with a tag such as v1.0.0.

7. When a bug is found in production, we need to pull a hotfix branch (such as hotfix-1.0.1) from the corresponding tag (such as v1.0.0) and fix the bug on that branch. Once the bug is fully fixed, merge the code from the Hotfix branch into both the Develop and Master branches.

We also have requirements for the version number, which is in the format of X.Y.Z. X will be upgraded only when there is a major reconstruction, Y will be upgraded only when a new feature is released, and Z will be upgraded only after a bug is modified. For each microservice, we need to strictly follow the above development pattern.

Differences with Git Flow model branch management:

1. After the feature branch is developed, it will not be merged into Develop temporarily. Instead, it will open the release branch based on Develop and merge the feature branch into the release branch for testing.

2. After the release branch test passes, deploy to production, merge the Release branch code into the Develop and Master branches, and tag the master branch.