Introduce to you

$ brew install git-flow-avh

Initialize the Git repository

The following commands are executed for a folder with README.md only. A conditional partner can follow them to improve memory.

$ git flow init
Initialized empty Git repository in /Users/savokiss/demos/gitflow/.git/
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/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] v
Hooks and filters directory? [/Users/savokiss/demos/gitflow/.git/hooks]

You can see that the git flow init command requires you to select two main branches and a prefix for multiple functional branches, all of which use the default value, while the version number Tag prefix uses v

It should be noted that git-flow is actually just a combination of a series of GIT commands, and init commands do nothing more than create new branches.So if you don't use git-flow anymore, you don't need to make any changes.

Notice that the init above is complete and will automatically cut us into the develop ment branch

Feature Functional Branch

Suppose we need to create a new feature branch, auth, to develop the login functionality.Let's cut into the master branch first:

$ git checkout master

Then start a new branch of functionality with the console output as follows:

$ git flow feature start auth
Switched to a new branch 'feature/auth'

Summary of actions:
- A new branch 'feature/auth' was created, based on 'develop'
- You are now on branch 'feature/auth'

Now, start committing on your feature. When done, use:

     git flow feature finish auth

You can see that we executed the command on the master branch, but the feature/auth branch was cut out based on development, because according to the branching model above, all functional branches should be cut out from the development branch.That's the benefit of git-flow. You don't have to worry about the branch you're currently in. It automatically helps you ensure that you don't cut the wrong branch ~

Next let's modify README.md and add one sentence login function is complete!And then submit.

Then execute the completion command, and the console output is as follows:

$ git flow feature finish auth
Switched to branch 'develop'
Updating e69b22c..f7f48e2
Fast-forward
 # gitflow | 0
 README.md | 4 ++++
 2 files changed, 4 insertions(+)
 create mode 100644 # gitflow
 create mode 100644 README.md
Deleted branch feature/auth (was f7f48e2).

Summary of actions:
- The feature branch 'feature/auth' was merged into 'develop'
- Feature branch 'feature/auth' has been locally deleted
- You are now on branch 'develop'

From the output, you can see that:

1. The feature/auth branch is merged into the develop ment branch.
2. feature/auth branch deleted
3. Automatically switch to develop ment branch

In 1, git-flow uses the following command, git merge --no-ff feature/auth, to merge. With regard to the--no-ff parameter, simply speaking, the feature history can be better preserved, and interested partners can consult the relevant information themselves.

Release version release

Usually, we use the semver Semantic version specifications for managing software publishing.

git-flow also supports the creation of release branches.Let's publish a 0.1.0 release:

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

Summary of actions:
- A new branch 'release/0.1.0' was created, based on 'develop'
- You are now on branch 'release/0.1.0'

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.0'

You can see that this command automatically cuts out the release/0.1.0 branch based on develop ment.
Then prompt you to do the following on this branch:

1. Modify software version number
2. Make bug fixes for this version

In the normal development process, the post-test bug fix phase can be done on this release/0.1.0 branch, and after the test passes, the release can be marked as complete:

$ git flow release finish 0.1.0
Switched to branch 'master'
Switched to branch 'develop'
Already up to date!
Merge made by the 'recursive' strategy.
Deleted branch release/0.1.0 (was f7f48e2).

Summary of actions:
- Release branch 'release/0.1.0' has been merged into 'master'
- The release was tagged 'v0.1.0'
- Release tag 'v0.1.0' has been back-merged into 'develop'
- Release branch 'release/0.1.0' has been locally deleted
- You are now on branch 'develop'

You can see that when you finish a release, the following actions are performed inside the git-flow:

1. release/0.1.0 branch merged into master and develop
2. Label v0.1.0 is marked on master
3. release/0.1.0 branch deleted
4. Currently switched to the develop ment branch

Hotfix Production Hot Repair

Since the master branch always reflects the conditions of the online production environment, it is necessary to cut out the master branch if hot repair is to be done. If there is a bug in banner on our line below:

$ git flow hotfix start banner
Switched to a new branch 'hotfix/banner'

Summary of actions:
- A new branch 'hotfix/banner' was created, based on 'master'
- You are now on branch 'hotfix/banner'

Follow-up actions:
- Start committing your hot fixes
- Bump the version number now!
- When done, run:

     git flow hotfix finish 'banner'

As you can see above, a hotfix/banner branch has been cut out from the master.
You can then submit production bug fixes and change the version number in this branch.

It should be noted that the hotfix branch is similar to the release branch, the only difference is that the hotfix branch is cut out based on master.

Let's first modify the README.md file and submit it it, then complete the bug fix:

$ git flow hotfix finish banner
Switched to branch 'develop'
Deleted branch hotfix/banner (was c6da343).

Summary of actions:
- Hotfix branch 'hotfix/banner' has been merged into 'master'
- The hotfix was tagged 'vbanner'
- Hotfix tag 'vbanner' has been back-merged into 'develop'
- Hotfix branch 'hotfix/banner' has been locally deleted
- You are now on branch 'develop'

That's done:

1. The hotfix/banner branch is merged into master and develop
2. This hot update is automatically labeled vbanner (because we prefixed it with v)
3. hotfix/banner branch deleted
4. Currently switch to branch develop

Since I don't have a remote origin associated with me, only the local branch will be prompted to be deleted, and if so, the remote branch will also be deleted.

Finished

Above we have experienced the basic operation flow of git-flow.For demonstration purposes, I'm based on an empty project. I can actually do a git flow init for a git repository that has been developed for a long time. It allows you to select an existing branch as a production and development branch and enter the appropriate prefix. The rest will not do any extra work.

Sourcetree is also a free, easy-to-use Git graphical client that supports both Windows and Mac, and has a built-in git-flow tool that interested little partners can try ~

For more information, see the link at the end of the article, where a cheatsheet can quickly familiarize itself with the git flow command.

I believe that with the git-flow tool, branch management can be relatively painless ~

Reference Links

• git-flow avh version
• semver Semantic Version Specification
• Using git-flow to automate your git branching workflow
• git-flow workflow
• Chinese version of git-flow cheatsheet

Welcome to my public number: codingonfire

Update an original or translated article every week~