How do you configure merge checks and default reviewers in Bitbucket to enforce code quality?

Think of merge checks as a pre-flight checklist before an airplane takes off. The pilot (developer) might feel ready, but the checklist (merge checks) ensures every system has been verified: engines checked (pipeline passing), passengers seated (tasks resolved), cabin crew approved (reviewer approvals). No pilot can skip the checklist, no matter how experienced.

Merge checks in Bitbucket are configurable rules applied at the repository or project level that prevent pull requests from being merged until all conditions are met. In Bitbucket Cloud, you configure them in Repository Settings > Merge Checks. Available checks include: minimum number of successful builds (the pipeline must pass), minimum number of approvals (reviewers must approve), all tasks must be resolved (inline tasks from code review), and no changes after last approval (prevents sneaking in last-minute changes). When any check fails, the Merge button is disabled and a message explains which conditions are unmet.

Default reviewers complement merge checks by automating who reviews code. You can set up rules that automatically add specific users or groups as reviewers when a pull request targets a particular branch or modifies files matching a path pattern. For example, you can ensure that any PR changing files in the infrastructure/ directory automatically adds a platform engineer as a reviewer, or that all PRs targeting the main branch add a tech lead. Default reviewers reduce the chance of code being merged without the right eyes on it. In Bitbucket Cloud, this is configured through Repository Settings > Default Reviewers, where you specify conditions (source branch pattern, destination branch, file paths) and the reviewers to add.

In production, teams layer merge checks with default reviewers to create a comprehensive quality gate. A typical configuration requires two approvals from default reviewers, a passing pipeline, no unresolved tasks, and resets approvals when new commits are pushed. Some organizations use Bitbucket's premium feature of required merge checks at the workspace level, enforcing minimum standards across all repositories. Teams also create custom merge check apps using Bitbucket Forge or Connect that integrate with external quality tools like SonarQube, requiring that code coverage stays above a threshold or that no critical security vulnerabilities are introduced.

A common gotcha: default reviewers are suggestions, not requirements, unless combined with a merge check that mandates their specific approval. Simply adding someone as a default reviewer does not prevent merging if they have not approved. You must also set a merge check requiring that specific user's approval, or set a minimum approval count that effectively requires their review. Another trap is that merge checks apply to the merge action, not the PR creation. A developer can create a PR, get it approved, then push a breaking commit that resets approvals, but the merge check catches this and prevents merging until re-approval happens.