Briefly describes the Git Flow

First of all, Git Flow is not a substitute for Git. Git Flow is just a combination of standard Git commands with scripts to form effective and simple commands.

Git Flow is just to give us an easier workflow command, but more importantly we need to learn and understand the workflow of the version control system in order to effectively iterate products and avoid confusion.

When the project is in a collaborative state, workflow is very important. Assuming that two or more developers are working on new features at the same time, there will be a lot of conflicts if they collaborate on the same branch. The way of working process is that each developer can cut out a separate branch, and when each function is implemented and tested successfully, it can be merged into the master branch, even without waiting for other functions to be implemented and released together.

Branch application scenario

In Git Flow, the main branches are master, develop, hotfix, release, and feature. The master and Develop branches are the most common ones. They are known as long-term branches and survive throughout the workflow, while other branches are mostly deleted when tasks are completed.

The master branch

This branch is used to store stable, ready to go releases.

The source of this branch can only be merged from another branch; developers do not commit directly to this branch.

We usually tag commits on this branch with a version number as well.

Develop branch

This branch is primarily the base branch for all development.

When functionality is added, all functionality is cut off from this branch, and when the functionality branch is implemented, it is merged back into this branch.

Hotfix branch

When an emergency occurs in an online product, a hotFix branch is opened from the master branch to fix it.

When the hotFix branch is fixed, it will be merged into the Master branch and also into the Develop branch.

The release branch

Once the Develop branch has completed the requirements, you can open a release branch from the Develop branch and do the final tests before going live.

When the test is complete, the release branch will be merged into both the Master and Develop branches.

Feature branch

When we need additional functionality, we will open a feature branch from the Develop branch.

After the feature is implemented, merge the Feature branch into the Develop branch and wait for the final test release.

Schematic diagram

Installation and use

The installation

Mac

brew install git-flow
Copy the code

If brew is not installed, use the following command to install it:

 /bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)"
Copy the code

Win

Install Git Flow for Windows

Initialize the

First clone the project to the local.

git clone <project-url>
Copy the code

Initialize Git Flow.

git flow init
Copy the code

The command line will prompt you to change the default branch prefix provided by Git Flow. The branching prefix varies by scenario, but by default it looks like this.

scenario	Branch prefix
New features	feature
pre-release	release
Hot repair	hotfix
tagging	empty

Which branch should be used for bringing forth production releases?
   - develop
   - master
Branch name for production releases: [master]

Which branch should be used for integration of the "next release"?
   - develop
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

The branch prefix is used to distinguish between different branches, and you don’t need to add the prefix manually when using Git Flow. Git Flow does it for you.

Usually you don’t need to change the default naming prefix, just add -d to skip the naming step.

git flow init -d
Copy the code

Feature scenario

When we need to develop a new feature, we need to pull out the feature branch based on the Develop branch for development, that is, the life cycle of the feature scenario begins.

In general, the full lifecycle of a scenario consists of at least one of the following behaviors:

• Start: Starts development
• Publish: Publish to the remote branch
• Finish: complete development and merge branches

start

Before a new feature is developed, prepare the development branch.

git flow feature start <feature-name>
Copy the code

After the preceding command is executed, a local branch named

is created and switched to the branch.

And no matter what branch you’re currently in, it’s localdevelopBranch created.

The above command is equivalent to performing the following Git action.

git checkout -b feature/<feature-name> develop
Copy the code

It is important to note that this branch is created from the local Develop branch, so executing this command usually requires pulling the latest remote code.

publish

After the new functionality is developed locally and committed, the local code needs to be committed to the remote repository.

git flow feature publish <feature-name>
Copy the code

This command does three main things:

• Create a name calledfeature/<feature-name>Remote branch of
• The local branchtrackRemote branch
• If there is code locally that has not yet been committed, commit the code

git push origin feature/<feature-name>
git push --set-upstream origin feature/<feature-name>
git push origin
Copy the code

When you need to commit code after publish, just run the normal push command.

git push
Copy the code

finish

Once the feature is developed, it will enter the test phase, where you need to merge the branch into the Develop branch.

git flow feature finish <feature-name>
Copy the code

The command also does three main things:

• Switch to thedevelopbranch
• Merge code intodevelopbranch
• Delete localfeature/<feature-name>branch

git checkout develop
git merge feature/<feature-name>
git branch -d feature/<feature-name>
Copy the code

Git Flow merge is a little different from the default Git merge.

By default, it checks how many commit records there are in the merge. If there is only one, it uses fast-forward mode, where the HEAD pointer is moved and no commit record is generated. If there are more than one COMMIT, the no-FF mode is used. In this mode, one more merge commit record is generated.

This has the advantage of facilitating code rollback and record monitoring when there are multiple commit records, and simplifying code commit records for easier management when there is only one.

If the merge conflict occurs during the finish operation, the finish operation will be terminated and the feature/

branch will not be deleted. The branch will also be in the Develop branch.

After the local conflict is resolved and commit, finish again.

In addition, the Finish directive supports three additional parameters:

• -r: Indicates that the merge is performed before the mergerebase, but evenrebaseAfter meetfast-forwardThe condition may not be usedfast-forward.
• -F: That is, the merge is complete and the remote branch is deleted.
• -k: Keep localfeatureBranch, do not executedeleteThe action.

Release scenario

When the new feature is developed, it will enter the test phase. At this time, you need to pull out the release branch based on the Develop branch for integration testing, or test the release scenario as a pre-release environment.

In this case, release generally has only a few changes.

start

Use start to start a release scenario.

git flow release start <release-name>
Copy the code

This creates a release/

branch based on the local Develop branch and switches to that branch.

Note that the start directive is not allowed to open a new release branch if there is a local release branch that has not been finished. This is a restriction on parallel publishing.

publish

In order for other collaborators to see the branch and test it together, it needs to be released.

git flow release publish <release-name>
Copy the code

finish

The official version shall be released after the test passes:

git flow release finish <release-name>
Copy the code

The actions of this command are as follows:

• git fetch, pull the latest code
• Merge branches intomasterbranch
• Generated,<release-name>thetag
• Merge branches intodevelopbranch
• deleterelease/<release-name>branch
• Switch back to thedevelopbranch

The process is not terminated if the merge conflicts, but the local release branch is not deleted. After the conflict is resolved, perform finish again.

Finish just completes a series of actions in the native code, and all branches and tags can be pushed using the following command.

git push origin --all
git push origin --tag
Copy the code

Hotfix scenario

Hotfix scenarios are used when a bug is found online and an emergency fix is needed.

start

git flow hotfix start <hotfix-name>
Copy the code

This command creates a hotfix/

branch from the master branch and switches to that branch.

finish

There is no publish command for hotfix, because Git Flow believes that hotfix should be a small scale change that does not require any collaboration.

After the local modification is complete and the commit operation is performed, the finish operation is performed.

git flow hotfix finish <hotfix-name>
Copy the code

This command does much the same thing as release: it pulls the code, merges the branch into the Master and Develop branches, tags them, deletes them, and then cuts back to the Develop branch.

Other code workflows

Similar to the Git Flow code management workflow and making Flow and [Gitlab Flow] [docs.gitlab.com/ee/topics/g…

• Github FlowIt’s a simplified versionGit Flow, it usesmainandfeatureTo manage code, which has only one long-term branch, which ismain.
• Gitlab FlowMore focused on continuous integration of code, a release needs to create a test environment, preview the environment, generate branches of the environment, and finally summarize tostable branchBranches are used for publishing.