[GuB-42]

The only thing that you seem to argue about is the naming of the branches.

If you call the git-flow "develop" branch "master" and the "master" branch "release-tags" it will be exactly as you describe. The names of the branches don't really matter in practice, so much that they could just decide to use "main" instead of "master" by default without much problems.

Maybe what bothers you is that you have a branch for tags, yeah, that's an extra level of indirection, but this lets you separate between user facing information in the master branch commits and developer facing information in the release branches commits.

Having the master (default) branch only contain releases let users who pull the project without knowledge of the process get a release version and not a possibly broken development version, which I think is nice.

Anyways, these are just details, I don't think the "git gods" (Linus) care about how you organize your project. There is only one sacred rule I am aware of: don't destroy other people history. Public branches you pushed that others have pulled is other people history.

[creshal]

> Maybe what bothers you is that you have a branch for tags, yeah, that's an extra level of indirection, but this lets you separate between user facing information in the master branch commits and developer facing information in the release branches commits.

That's such a marginal niche use case to build your entire organization around… why would you make this the default approach?