[Alexandervn]

Yeah, we also use something like this for building a website/webapp (for a client) with 5-10 people.

- Feature branch: do whatever you want

- Develop: should be good enough for the client (product owner) to look at

- Release branch: should be good enough to be tested by the test/QA team

- Master: should be good enough for website visitors

Branches are meant to be shortlived and merged (and code reviewed) into develop as soon as possible. We use feature toggles to turn off functionalities that end up in develop but can not go to production.

[Touche]

The problem with having too many eternal branches is that they quickly become unmergeable. The nice thing about feature branches is that it's the author's responsibility to make it mergeable. But if you having a bunch of eternal branches none of which are "owned" by one person, when it comes time to merge them and there's dozens of merge conflicts there's not one person that can set down and know what the correct fix is for all of them.

[madeofpalk]

I think the idea is that the branches cascade. You would never create new commits directly into release or master, the flow would only ever be develop > release > master, thus making merge commits and conflicts impossible.

[Touche]

That doesn't work in practice, you are always going to need to "fast-track" a bug fix, skipping develop (which has code you don't want to deploy).

[rjv]

That's exactly what hotfixes are for. A completed hotfix will merge directly into develop and master simultaneously (practically speaking). This allows you to keep your unrelated develop commits out of the master until you're ready to merge it all.