Is this considered an actual merge commit (where the commit has 2 parent commits?) or is it the default squash commit syntax that BitBucket uses?

Firstly, PSR does not support squash commit parsing at this time. It is in work but is not fully tested (and therefore not released yet).

Secondly, It is my recommendation to actually ignore actual merge commits completely. You can read my rationale on issue #540, comment.

BitBucket (BB) supports both merge and squash commits on PR merges. We use squash commit to keep the main branch history clean.

We follow the trunk-based model, with one PR per feature (and therefore one semantic tag). The trunk branch history is squash commits (one per PR), with the commit message that looks like above.

BB does put squashed commits messages below, but they don't have semantic tags in our case.

With this model squash commits are no different from regular commits. We'd like to use them to bump semantic versions and generates a change log.

Giving users an option to match semantic tags after the first line would be very useful for BitBucket users, and people can use this if that makes sense for their use case.

As a workaround, you will have to use the merge commit strategy with Bitbucket currently. The parser that supports squash commits will hopefully be released in the upcoming months and it should work for your use case at that time.

There will be an option to toggle on parsing of squash commits added to the parser_options configuration setting. It will need to be set by you as I am not going to set the default to always parse squash commits until the next breaking release.

Although your option 1 & 2 are possible solutions, they would introduce edge cases that do not follow the angular or conventional commit standard as they are specific to starting on the first line of the commit (ie the subject line). The squash commit implementation I am working on deliberately breaks each portion of the commit up by a double newline and then evaluates if the first line matches the commit convention at that point they become arbitrarily different commits within PSR when passed to the changelog. This allows us to handle version determination and changelog formatting correctly. In your case the Merge ... line will just be considered a ParseError object and if you have set exclude_commit_patterns accordingly, it will be ignored.

🎉 This issue has been resolved in Version 9.17.0 🎉

You can find more information about this release on the GitHub Releases page.