At my previous job, we had this discussion as well, and the chosen branching model was Release Flow, as used by Microsoft. It has release branches and feature branches, optionally uses rebasing, and no merges. Main distinguishing feature is that hotfixes are committed to master and then elevated/cherry picked to the feature branch.
Our reasoning was as follows:
We still wanted release branches, as they can provide extra stability (for example performing extra tests manually). This could later be changed to better suit continuous integration, but stability was an important factor.
We want to enforce that a fix that lands in a release branch also lands in any following release branches (it had happened before that a release branch containing a hotfix wasn't merged back into master, as can possible happen with flows like Trunk Based Development and OneFlow).
Hope this gives some more insight!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
At my previous job, we had this discussion as well, and the chosen branching model was Release Flow, as used by Microsoft. It has release branches and feature branches, optionally uses rebasing, and no merges. Main distinguishing feature is that hotfixes are committed to master and then elevated/cherry picked to the feature branch.
Our reasoning was as follows:
Hope this gives some more insight!