I am about to say something heretical.
Have you considered that "gitflow" isn't the right practice for your organization?
Here's a really BIG problem in our industry: we look at what the "big shops" like the FAANGs are doing and adopt it as our own best practices. But they are NOT facing the same business and technical problems you and I are. git wasn't designed for general application work, it was designed to suit the needs of the Linux kernel team, run by Linus Torvalds. When a PR gets issued in that situation, the code hasn't been merely unit tested, there's a really good chance that it has been real-world tested in some way too. This isn't "I built a user story, please check it out" or even "I made a small change, please review", it is "I made a change that will potentially have catastrophic impact to quite literally the entire world if it is not good, we have thoroughly tested it as a separate, independent team, and we would like this to be considered for inclusion into the main Linux kernel branch".
Can you see how that is a different use case from what you are doing?
Now, I'm not saying "gitflow" is always *bad*. It's not! And it has its place. But it's place is not in the toolbox of every single development organization around the world.
Likewise, microservices are great at addressing the problems that Netflix has in making sure than a 7 year old smart TV that will *never* get an update continues to work fine while the newest versions of the client can use the newest version of the APIs too... but do I really need the massive amount of infrastructure engineering, DevOps effort, etc. for the CI/CD pipelines, etc. etc. etc. for a "project" where the client wants to do UAT on one "big bang release" and then do a month or two of bolt tightening afterwards and then not touch the code for months if not years?
I don't know your environment or your projects or your organization.
But what I do know is that, as an industry, we fall into some really bad habits:
* We build bike sheds when we need to build pyramids, because there isn't enough business value in the pyramid to justify the time and effort.
* We build pyramids instead of bike sheds when there isn't the business value in the pyramid, because the pyramid was the more technically "interesting" approach or because we convinced the business it was "needed" because it was "right" or "elegant".
* We latch onto ideas not because they are appropriate for our organization or our projects, but because someone with a bit of fame says "this is what we do in our organization"... or worse, someone says "this is what some famous organization does, and if you don't do it, you are not doing a good job".
Bottom line is that as an industry, we often fail to align needs, approach, practices, and process to the ROI and business value, and too often let emotions like shame, embarrassment, fear, anxiety, etc. guide technical decisions that we need to make with a clear and focused mind.
I find that the relentless drive to use "gitflow" to be one of those. Not saying it's wrong for you and your organization, that's for you to decide. But from what you are describing, maybe it's not "wrong", but perhaps it is "not ideal" or "flawed"?
J.Ja
