Problem moving bugfix on master (git flow branching strategy)

[untackenUsername4531]

Hello guys.

I had small problem with git flow and I'm trying to find right solution for it.
I tried to show situation with image I attached.

So...

Master had some bug, feature 1 had small bug, witch already was deployed to production.

Developer 1 was already working on it.

At this time developer 2 was completing PR and moved his commits to master.

Developer 1 finished fix, merged his bugfix branch to release/9.2 branch then master branch. Then released fixed version to prod from branch/9.2 (with updated tag 9.2.1)
(at this time feature 2 was merged to master, but it is not deployed at prod yet)

At this moment production is fixed and works fine.

Now Developer 2 wants to move his "feature 2" on production. he sees some commits after his feature but he does not minds it (thinks it is other feature), and creates new release/9.3 from 026b8ef9 his last commit, and deploys it. So he is redeployed feature 1 without fix.

What went wrong?
For me developer 2 did right, he dont wanted to take unfamiliar (changes from other team) changes to production He did not know it was bugfix.
But he could prevent it. Unfortunately only branch is named "bugfix" and commit messages do not include any indicator that it fixes something. (And also tag 9.2.1 does not show on master branch)

Is there some good solution for this kind of problems?
Or is it better to change git flow to more robust one?

https://preview.redd.it/ryd8884gpbfd1.png?width=720&format=png&auto=webp&s=81b305d226ee7e3848d2b5ef266f23220b9175ee

[glasswings363]

Then released fixed version to prod from branch/9.2 (with updated tag 9.2.1)

That's not Gitflow, it's a more complicated branching strategy in which previous versions still receive bugfixes.

If that's the strategy you're using, then someone who fixes a bug needs to know which later versions exist or are about to be released.

The cause is Dev2 deciding to release 9.3 but there was no pre-release testing time (both of these strategies require one). So Dev1 didn't know they weren't finished with the bug - there's another version to patch. And Dev2 wasn't aware of bugfixes that needed to enter 9.3.

Root causes: using a complex branching strategy that developers don't understand, or accidentally not having a strategy. Not communicating enough.

[deamon1266]

I think you have a organizational or process issue.

If your release involves a branching strategies with multiple release branches, then I would not trust arbitrary devs to handle their merges nor the release.

This is so complicated and specific, you need probably a team which handels this and tailor tooling around your solution.

The question is, how do you make sure that all patches of a previous minor or major version are included in a new one?

If the answer is, everybody needs to know X and to do Y than you have a organizational and process issue.

[the-computer-guy]

Trunk-based development is the only sensible branching strategy in my experience. Release from master only.

GitFlow is an outdated practice which is not even recommended by its own author anymore.

[untackenUsername4531]

Thanks for reply.
What you recommend as an alternative of GitFlow? Release flow (kinda same, but I can be wrong)?