## TL;DR

Treat visual baselines like code: branch them with the feature branch, run comparisons on the PR, and merge baseline updates only when the PR merges. The workflow: the PR run produces new screenshots, the team reviews the diffs in the PR, approved diffs become the new baselines on merge. This stops the classic mess where one person's "accept all" overwrites another team's baselines, and it makes baseline changes reviewable like any other change.

## The query

```text
visual regression baseline branching strategy for teams
```

## Use this when

- Baseline updates conflict or get lost across branches.
- "Accept all changes" has burned the team before.

## Not for

- Picking a visual regression tool.
- Pixel-diff tuning; this is process, not thresholds.

## Steps

1. Configure your tool to store baselines per branch, falling back to the main branch baseline. Expected output: feature branches compare against main, not against stale images.
2. On each PR run, collect changed screenshots as reviewable diffs attached to the PR. Expected output: reviewers see visual diffs next to code diffs.
3. Require explicit approval of visual diffs before merge. Expected output: no silent baseline changes.
4. On merge, promote the approved screenshots to the main baselines automatically. Expected output: main baselines always reflect merged, reviewed UI.
5. Prune baselines for deleted components monthly. Expected output: the baseline set stays small and relevant.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7dYcSoJZnw3uJI7lkSjHtQ