In Git flow, there are two consistent branches:
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.
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
This is the Git flow development process, and it looks like a lot of work, but it’s actually done by an existing tool.
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
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!
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
develop branch respectively.
`hotfix back into
master, you also need to tag
master branch with
too-many-water to indicate that it is a
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
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
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
master branches. develop
branch, then the code of thedevelop
branch and themaster` branch will be out of sync.
What is the problem with
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
The solution? I haven’t explored other people’s solutions, but I think a possible solution is to merge
hotfix` into the nextmaster
and ``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?