Bugs can always be introduced into master.
The question is where do you want to discover them? You either run tests against the feature branch before merging or you have to gate your master branch into a version on a test system before it is promoted to production.
CI/CD can be chaos but the Facebook philosophy is that we would rather you delivered 1000 features per day and be able to quickly fix anything you might break in the process rather than release 1 thing a day that is fully tested. Might not work for your system but it makes sense to them.
>Bugs can always be introduced into master.
Or you can cut a release branch, test, and iterate on that branch and be secure knowing only those release iterations are being made.
Its fine for master to have bugs if you're on a release branch. That's why people use them.
You can avoid “bugs introduced by the merge” by requiring a fast forward/semi-linear merge (ie, the source branch must be a superset of the destination branch). Any testing or validation of the source branch is therefore valid for the result branch, as the contents of the source and result are identical.
To actually ensure a fast forward merge you need to get your testing done while no changes can be made to master. If you were to actually enforce this it can really lock up development. If you're doing any manual testing its untenable. This is why release streams and hotfixes are used.
If master can be unstable then you can't seamlessly release and must test.
If you need to keep master stable then it can't be easily merged into by developers. (testing a tag is not enough because iterations with have other changes in the mean time.)
People attempt to skip these issues by embracing the chaos with CI/CD but that's outside the scope of the branching strategy. Maybe the simple flow is the best but it has clear stumbling blocks you will hit.