Is a develop branch useless in git-flow?

Question

Everywhere I look for the right way to use GIT in a team, we always get referred to git-flow.

We started to use this scheme as our bible at the beginning:

Time passed, and we finally found that keeping master as the stable branch with tagged commits was a waste of time.

Why would you TAG your stable commit and then PUSH to master the same version you already tagged? The tag exists, you may return to this commit any time. Why should I bother to keep this branch just to contain only the tags?

Here is the flow we use, and it works like a charm:

• Master : Is actually our development branch

• Release: We create a release branch to do our last release test case then we add fix if needed.

• Feature: We branch from Master to create a feature then we send the pull request to master.

Actually, it's the same as git-flow, without a branch containing stable.

Another advantage of this, is that master is the develop branch. So when a new teammate comes in the project, he may start by cloning the project and his master is already up to date with the actual development.

In image:

My question is, why would you use the original git-flow with 5 branches if you could manage only 4 branches with the same result?

Answer 1

In my opinion, your workflow has a big problem: over-use of develop/master branch.

You are basically saying that there is no need to distinguish between master and develop because keeping tags on develop is enough. And it seems reasonable at a first glance, but the image you have modified is hiding the need for a branch: the hotfix.

Let's suppose you have a stable version of your code and you have already completed the release phase. Now you believe that everything is ready and create a tag on master/develop. After some time your customer makes you notice you have a bug and you are not ready for a new release. What do you do?

Your only choice is branching from master/develop. So, features, release and hotfix will come out from master. Another drawback of this approach is that once a bug has been resolved on the hotfix branch, you will merge it in develop/master but you cannot put a tag on that commit because develop/master branch probably moved on meanwhile and it will have more (not tested) features that the customer should not have. I think that is too much and the commit history will be hard to understand at some point. BUT, as I said at the start, this is debatable.

Your workflow seems to mix git-flow and trunk(or master) based development, but mostly taking disadvantages from them.

Answer 2

The result is not the same: In plain git-flow master is always stable - this is your deliverable people outside your team can rely on. Your master is a mixture of develop and master in gitflow-speak. After merging a big features the bets are off whether the result is really stable and ready to ship or some more bugfixes are required.

That said: Git workflows are not god-given. Git-flow got quite some critics. If your team and the teams which rely on your code are happy then go with the workflow with minimal overhead.

Last note:

Here is the Git-Flow we use and it works like a charm.

Please do NOT call your workflow "git-flow". Choose a clearly different name. Diluting a good search term doesn't help anyone.