It may happen because you may assume This can happen when assuming different default behavior than YACC provides. You can refer to documentation on details of Refer to Oracle's documentation for details on Java Regex engine defaults and available options.
Below Here are listed some of the most common cases when the expected regex behavior may does not match YACC defaults.
The . character in regex is not matching newlines
If you use a regular expression to match multiple lines of a commit message, it may not behave as expected – this is because by default, in Java regular expressions, the . character doesn’t match newlines.
...
Explicitly include the newline character in your regular expression, e.g.
(.|\n)*Put Add
(?s)at to the beginning of your regular expression. This enables Pattern.DOTALL, meaning that the.character will also match matches newlines.
The ^ and $ are not matching every line in
...
a multi-line input
By default, these expressions only match at the beginning and the end of the entire input sequence. To enable Pattern.MULTILINE matching mode, add (?m) prefix to your regex. In multiline mode, the expressions ^ and $ match just after or just before, respectively, a line terminator or the end of the input sequence.
Case-sensitive matching is performed.
By default, YACC distinguish distinguishes letter cases. You can add Add (?i) prefix to your regex to perform case-insensitive matching.
The commit message contains unexpected text
Bitbucket automatically inserts commit summaries in pull request merges, which may can complicate commit message regex checks:
...
Options to work around this:.
Workaround options
Disable checking of merge commits , by enabling the “Exclude Exclude Merge Commits” Commits option from the YACC Exclusions tab.
Turn off commit summaries in pull request commits (Bitbucket 6.7+) as described here.
Update your regex to allow the commit summaries on pull request merge commits.
...