[jimeh]

The issues I have with Git Flow isn't feature branches, it's the develop branch, and the whole crazy merge dance between develop, release, and master branches. It doesn't provide much benefit and more often than not causes confusion and and problems.

What I'm in favor is is GitHub Flow or anything very similar to it, which just has master and feature branches, nothing else.

[geezerjay]

> The issues I have with Git Flow isn't feature branches, it's the develop branch

What's wrong with that?

> and the whole crazy merge dance between develop, release, and master branches.

I really don't understand your problem. What's so crazy about separating a stable from an unstable branch, and avoiding to push unstable features when you're preparing a new release?

> It doesn't provide much benefit

I see you never were forced to work overtime just because an overzealous manager decided to merge into a release an unstable feature that ended up triggering crashes in a client.

Do you know what's a good way to avoid that problem? Keeping a stable branch, and not confounding a release with the current state of the development branch.

Whenever I see these sort of complains it appears that the only people who complain about the need to organize a project around separate branches dedicated to track main, release and development branches are people who don't have much (if any) experience working on real-world software development projects.

[jimeh]

I have no issues with separating the latest greatest development work from production ready code, I just think the way Git-Flow does it is needlessly complicated with multiple points of redundancy.

For example, the master branch is only ever updated when a release (or hotfix) branch is merged in to master, at which point you also tag master with the release version. Why do you need both a tag and a branch pointing at the latest release?

Instead of ignoring tags, why not use only tags to define releases? At which point you can get rid of master as defined by Git-Flow, and rename develop to master, so you just have a master branch. If the release process (QA, etc.) is lengthy, by all means create a release branch from master to avoid a change freeze. When ready for release, create the release tag on on the release branch and merge it back into master if needed.

Also the whole "feature/" and "hotfix/" prefixes on branch names feels pointless. Why not just call them all "change branches"? Anything that changes stuff, is a change branch. And how about we enforce descriptive names on branches like "add-2fa-support", "fix-login-issue", "update-font-awesome", and "change-search-behavior"? No prefixes needed and yet the purpose of the branches are perfectly obvious.

If I'm not sounding like a complete idiot here, please do have a look at Git Common-Flow [1]. I'm genuinely interested in hearing your feedback about it. Again, full disclaimer, I am the author of Git Common-Flow.

[1] https://commonflow.org/