> Or you could use topic branches for new features, and fix bugs on master at the same time.
One could but it's often very desirable to integrate branches fast. If merging is delayed by a release there will be stale branches to merge. The experience of merging long branches scares people off of refactoring, because a refactoring creates more conflicts the longer it stays unmerged.
> 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.
As long as you have sequential merges there is no problem. But when you merge into the main branch and it is ahead of you (due to another merge) the build may become broken. You can merge the other way first, sure. But if you want to enforce this you need support from your infrastructure.
The only way to be sure: CI checks out master, merges the feature branch, and tests that version. If successful, push to origin. If the push fails (because a parallel pushed happened in between) start from the beginning.
The challenge here is that pull request might be tested again and again. It increases the CI load by some factor for large projects.
One could but it's often very desirable to integrate branches fast. If merging is delayed by a release there will be stale branches to merge. The experience of merging long branches scares people off of refactoring, because a refactoring creates more conflicts the longer it stays unmerged.
> 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.
As long as you have sequential merges there is no problem. But when you merge into the main branch and it is ahead of you (due to another merge) the build may become broken. You can merge the other way first, sure. But if you want to enforce this you need support from your infrastructure.