Targeting branches

Use glob patterns to control which branches trigger ADO Pilot reviews. Examples for trunk-based and GitFlow workflows.

Last updated 2026-05-05

You decide which branches trigger reviews using target branch filters. ADO Pilot reviews a pull request only if the PR's target branch matches at least one filter. Filters use glob patterns and stack additively across organization, project, and repository scopes.

What the setting controls

Field	Type	Default	Scope merge
`targetBranchFilters`	array of glob patterns	`["*"]`	Additive

The filter is matched against the target branch of the PR (the branch a developer is merging into), not the source branch. A PR from feature/login into main is matched against main.

Set this in the onboarding wizard alongside repository selection. See Choosing which repositories get reviewed for the wizard path.

Glob pattern syntax

ADO Pilot uses standard glob patterns, the same syntax you use in .gitignore.

Pattern	Meaning	Matches
`main`	Exact match	`main` only
`release/*`	One path segment after the prefix	`release/v1.0`, `release/v2.1`
`release/**`	Any depth after the prefix	`release/v1.0`, `release/v1/patches/v1.0.1`
`hotfix/*`	One path segment after the prefix	`hotfix/auth`, `hotfix/db-pool`
`*`	Any single-segment branch	`main`, `develop`, `staging`

Branch names are matched case-sensitively against the short ref (for example, release/v1.0, not refs/heads/release/v1.0).

A PR is reviewed if its target branch matches any pattern in the merged list.

Example: trunk-based development

Teams that commit directly to main and ship from there typically only need reviews on PRs into main.

targetBranchFilters:
  - "main"

Outcomes:

PR from feature/login into main — reviewed.
PR from experiment/new-router into develop — skipped.

Example: GitFlow

GitFlow uses main for stable releases plus long-lived release/* and hotfix/* branches. Review all three.

targetBranchFilters:
  - "main"
  - "release/*"
  - "hotfix/*"

Outcomes:

PR from feature/payments into release/v2.0 — reviewed.
PR from release/v2.0 into main — reviewed.
PR from hotfix/csrf-token into main — reviewed.
PR from feature/payments into develop — skipped (no develop filter). Add develop to the list if your team uses it as the integration branch.

Additive merge across scopes

Branch filters from every scope combine. If your organization defines ["main"] and a single repository adds ["release/*"], that repository's effective filter is ["main", "release/*"]. There is no way to subtract patterns at a narrower scope — to remove a pattern, set it only at the repository level and leave the broader scope blank.

See Org, project, and repo settings hierarchy for the full merge rules.

Interaction with other settings

Repository disabled (enabled: false) — No reviews regardless of branch filter.
Branch matches the filter — Review runs (subject to RC quota and file exclusions).
Branch does not match the filter — PR is skipped, no RC charged.
Manual review — Subject to the same branch filter as automatic reviews. A manual trigger on a PR whose target branch is outside the filter is skipped. See Manual vs automatic reviews.

Why narrow the filter

Cost control — Skip experimental and personal-fork branches to preserve RCs for branches that ship.
Compliance — Some organizations only require AI review on protected branches. Match your filter to your branch policy.
Signal-to-noise — Reviewers spend less time on draft branches if those branches do not generate review threads.