Skip to content

Branch-prefix strategy

The branch-prefix strategy inspects the subject line of each commit and picks a bump if the subject (a) looks like a merge commit and (b) contains a configured branch-name prefix. It is the default strategy because it works out-of-the-box on repos that merge via short-lived prefixed branches and use the default git merge behavior.

Default prefix-to-bump table

Substring in commit subject Bump
feature/ minor
bugfix/ or hotfix/ patch
anything else none

A bump of none means the commit contributes nothing to the release decision. Major bumps are not produced by branch-prefix — promote to a new major version manually, or switch to Conventional Commits which recognizes feat! and BREAKING CHANGE:.

Merge-commit detection

The strategy only fires on commits whose subject contains the literal string Merge branch (the default git merge subject). Commits without that text return none regardless of prefix. This means:

  • Standard git merge feature/foo → subject Merge branch 'feature/foo' into main → bump = minor ✓
  • GitHub's "Merge pull request #N from user/feature/foo" → does NOT contain Merge branch → bump = none under defaults.
  • Direct pushes to the default branch → bump = none.

The merge_mark_text is configurable (defaults to Merge branch); adapt it for non-default merge-commit conventions.

Customizing the prefixes

The strategy reads its prefixes from the application's settings layer:

  • minor — tuple of prefixes that trigger a minor bump (default ("feature/",)).
  • patch — tuple of prefixes that trigger a patch bump (default ("bugfix/", "hotfix/")).
  • merge_mark_text — substring that marks a subject as a merge commit (default Merge branch).

These are set via the same pydantic-settings env-var mechanism used for tokens / endpoints — see the provider docs for the variable naming convention.

When to pick a different strategy

If your team commits Conventional Commits messages directly to the default branch (without merge commits), switch to Conventional Commits — that strategy scans every commit since the last tag and does not depend on merge metadata.

Consumer integration

The strategy is selected per project via the strategy: input on the relevant provider's component / action. See:

  • GitLab CI — set strategy: branch-prefix on the include: - component: block.