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?

Fomalhaut

You may be interested by the CPython Git workflow. They don't use a develop branch but the master for development, and support branches for the long term maintenance of multiple versions in parallel. – Twotone

Answer 1

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.

Cousteau

I will update my question to avoid using Git-flow since it's not a git flow. thanks again for you answer! – Fomalhaut

With @ChristopheChenel 's method then the "always stable" code is the end of the release branches – Sandhurst

Answer 2

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.

Alva

I think this answer points out the biggest issue with the Question's proposed flow: by combining Develop and Master, it's impossible to deploy a hotfix for a previously-released-and-tagged revision without also including unreleased develop stuff. – Hurdygurdy

For my hot fix, if I checkout the last Tag (version I sent to the customer) then I branch a relase/version-with-the-hot-fix. Then in this branch I fix the issue tag it. release it and send the pull request for Master (My active development branch). It looks like by this way I by pass the "disadvantage" or I am missing a point. – Fomalhaut

If I understood this correctly the problem persists: even with a pull request, develop/master might not be ready to create a stable version with your bug fix, especially because you have to commit the bug fix in the shortest time possible. Actually this is an even worse choice if you think that you are creating a bottleneck in your workflow. While with the git-flow you could have a develop team and a master team, now they are both blocked by the necessity to integrate your bug-fix. – Alva

In your example, what happens if you need to create a second hotfix? It would need to include the changes from the first hotfix, plus the new hotfix, but nothing else from master/develop. When the first hotfix is merged back through PR, it merges at the HEAD of develop/master at the time. So, you cannot create a second hotfix from that first hotfix merge point. – Starveling

Hotfixes can branch from a tag and since they eventually become tags themselves the process is exactly the same for a second or third hotfix. The process as described works. reallifeprogramming.com/… – Zola

Answer 3

One year latter,

I finally understand the necessity of two separated branch in the git flow.

The only reason you would need the Git-flow is when you have a CI/CD with automatic deployment to production via any commit you make into master branch.

Last year when I asked the question, we didn't have any automatic deployment to production. So we may consider that the method we used without Develop/Master was ok and it saved us a bit of time since we didn't have to manage one more branch.

Since we use the pipeline system (Release to production after any commit into Master Branch), it gives a purpose to this branch! Yes, the master branch contains the tagged version, but the script for an auto-deployment to production environment is also attached to it!

Fomalhaut

The merge to master is done by a human right? Couldn't that same human just directly start the deployment pipeline on release branch? – Sandhurst

Your pipeline can start deployment based on tags, rather than a branch. Your original workflow is good. Nothing wrong with it. The master branch in git flow is useless. reallifeprogramming.com/… – Zola

The pipeline could also create multiple manual jobs, so those deployment environments could be selected each time based on whatever criteria your team likes. In cases where there is only one possible environment, the jobs could be automatic instead of manual (e.g. tag triggered pipelines automatically deploying to staging and/or production). – Leasehold