[fredrikmorken]

Author of the article here. You bring up some interesting points, and I would not be much opposed to the workflow you describe. However, as others mention, if the problem results from a combination of changes, I would expect the merge commit to be the one that contains the error. Moving this errror to a commit that was originally part of a branch without errors is just confusing to me.

[andrewaylett]

A merge should be just that: merging code without adding extra changes. If you need to make changes, they should be in a separate commit.

But if you had to resolve conflicts in a merge, you might also have had to make changes, and now you've got to work out whether the breakage was because of the combination of features that hadn't been tested together before or because someone changed something while resolving conflicts. Speaking from experience, that's really difficult.

If you rebase instead, the commit that breaks the build contains the code change that breaks the build, and if it's because of a rebase error you've got the opportunity _as you're rebasing_ to detect that.