In Git flow, there are two consistent branches: master and develop. master is the branch that you are not allowed to merge your code into, and develop is the base branch that you develop on and the branch that your features are merged into. Understanding these two concepts is a great way to use Git flow.

Development Flow

One of the most common scenarios you’ll see in Git is development. In a Git flow, you cut a feature branch out of the develop branch, such as feature/post-tag, which is the tagging feature for your blog. When you’re done, you merge your feature branch into your develop branch.

This is the Git flow development process, and it looks like a lot of work, but it’s actually done by an existing tool.

Release Process

When you feel at some point that your code is stable and ready to be released to users, you can cut out a release branch on the develop branch, such as release/v1.2.3, and add some release notes and such to the release branch, and then you can add the After merging the release branch into the master branch, tag the newly merged commit on the master branch with the name of the release branch: v1.2.3.

Also, merge the release branch back into the develop branch to ensure consistency between the master branch and the develop branch. Finally, delete the release/v1.2.3 branch, and that’s it for the whole release process!

Patch Process

When your product has been out for a while, you will encounter bugs more or less online, so the operation at this time is to switch the hotfix branch from master branch, for example: hotfix/too-many-water, then fix the problem on this hotfix branch, when the fix is done, then you merge the hotfix branch back to master and develop branch respectively.

After merging `hotfix back into master, you also need to tag master branch with too-many-water to indicate that it is a hotfix merge.


It looks neat and nice from the above description, but there are still a lot of problems in actual operation, so let me list some of the problems I have encountered here.

master and develop branches

From the above, it looks like the master branch and the develop branch are slightly redundant and you can just keep one.

My opinion is otherwise, in Git flow.

This means that at any given time, you can run a stable system from master, just like a stable version of Linux, and if you merge develop with master, you will need to actively switch to a Tag to achieve the same effect.

This is valuable in many scenarios, such as dynamically scaling systems where you can pull code directly from master when creating containers/virtual machines, and develop branches your CI/CD work.

toB product hotfix not working well

If you’re a toC Internet product, Git flow may be a good fit for you. However, if you’re a toB product, especially if you’re deploying at the user’s discretion, then the problem with Git flow becomes apparent.

If you have a v1.1.0 and a v1.2.0 release, and v1.2.0 is the latest release, then according to the Git flow workflow, your hotfix can only be done on top of v1.2.0. As a 2B product, it’s unlikely that you’d force users to upgrade to v1.2.0, since they’re probably running v1.1.0 on their machines. So what if there is a bug in v1.1.0 that requires hotfix?

There’s no way to directly hit hotfix on v1.1.0 with the current Git flow, of course, there’s been some discussion about a support branch or something like that, but the tool I described above doesn’t support it, and there’s no specification for it. If you are interested, take a look at the following discussions.

release Branch consolidation difficulties

From the front, it seems that merging a release branch into a master should be a very simple task, but in practice there are a number of problems with it. For example, if you’ve developed some features on the develop branch, and the develop branch is out of sync with the master branch, then if you have a hotfix, the Git flow specification requires you to merge into both the mastser and master branches. developbranch, then the code of thedevelopbranch and themaster` branch will be out of sync.

What is the problem with master and develop code being out of sync? First of all, you should know that Git is version control based on file changes, so if your base code is inconsistent, it’s likely that you won’t be able to merge it in naturally, and you’ll have to resolve conflicts manually. In fact, this is one of the reasons why so many people complain about the distinction between master and develop branches.

The solution? I haven’t explored other people’s solutions, but I think a possible solution is to merge hotfix` into the nextmasterand ``develop`` branch instead of ``master and `develop in a hurry, thus reducing conflicts to a minimum. This is where it gets tricky again.


OK, so that’s my understanding of Git flow or Git workflow, if you have some good practices or suggestions for Git flow or Git workflow, why not leave a comment?