From Vincent himself: "This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team."
The difference in practice is not between branching strategies, but whether coding practices are adequate. With good automated testing you will tend towards trunk-based development. With no good automated testing git-flow type of branching strategies will look like a good control mechanism but it's all an illusion. Manual testing and using purely eyes for code reviews do not scale. Many things come together to achieve continuous development
- good automated tests
- short-lived PRs/branches
- treat every commit as a release candidate
- fail fast and early
1. To test whether changes are compatible with target branch you have to pull target branch into source branch and test on the source branch not the other way round
2. A lower level understanding of git tells us gitflow and it's variants don't make sense because the state of truth should be associated with a commit. Adding hotfixes to a release branch whose history has already diverged tells us nothing if the same changes are compatible on another branch