> But you can't open a PR against a tag v1.0.0. Hence you discover that v1.0 should be a branch, and both v1.0.0 and v1.0.1 tags. This way you can open a PR against v1.0 and easily create v1.0.1, v1.0.2, etc.
So you could just `git checkout v1.0.0; git checkout -b v1.0`, commit your hotfix and deploy v1.0.1.
> Another problem. You are at "master" and approach v13.0.0. But there are numerous bugs to fix before you release. Testing takes >24 hours. You choose to work on bugs on a branch (v13.0) this way master can proceed with new features and not be feature-frozen for days or weeks.
Or you could use topic branches for new features, and fix bugs on master at the same time.
> Another problem. Your CI is deficient in that it allows merging and cloning before it makes sure that previous merge produced good product. Puny as it is, it is the current industry standard. Thus your main branch becomes broken now and then. So you call it "develop" and only merge it to "master" what you are sure is a good product.
I don't understand your point here. Usually your CI builds a branch, runs some tests on the compiled product and makes sure the `master` branch is ok before deploying to staging or production.
> If these common situations don't apply to you - proceed as you are. Do the simplest thing possible, but not simpler. What you've described doesn't create any roadblock or dead end street for the project.
I think there are a lot of branching strategies for a reason. Your use cases can be covered with other branching strategies as well.