How do pull requests work in Bitbucket and what review features are available?

A pull request is like raising your hand in a meeting and saying, 'I made these changes, can someone review them before we finalize?' It is a formalized code review process where the author presents their changes, reviewers provide feedback, and the code is only merged when everyone agrees it is ready.

In Bitbucket, a pull request (PR) is created from a source branch to a destination branch within the same repository (or across forks). The PR shows a unified diff of all changes, allows inline commenting on specific lines of code, and tracks the approval status of assigned reviewers. Unlike some platforms that use 'merge requests,' Bitbucket consistently uses the term 'pull request.' When creating a PR, you set a title, description, reviewers, and optionally link it to a Jira issue. If the source branch name contains a Jira issue key (like feature/PROJ-789-fix-timeout), Bitbucket automatically links the PR to that Jira issue.

Behind the scenes, Bitbucket supports several merge strategies: merge commit (preserves full history), squash (combines all commits into one), and fast-forward (linear history with no merge commit). Administrators can restrict which merge strategies are allowed at the repository or project level. Merge checks enforce quality gates: you can require a minimum number of approvals, passing pipeline builds, no unresolved tasks, and no changes after the last approval. These checks prevent premature merging.

In production workflows, teams typically require at least two approvals, mandate a green pipeline, and enforce the 'no unresolved tasks' check. Reviewers can create tasks directly from their comments, which the author must resolve before the PR can be merged. The activity feed shows all comments, approvals, commits, and pipeline results in chronological order, giving a complete audit trail. Bitbucket also supports 'needs work' as a review status, which is a signal that changes are required without outright rejecting the PR.

A gotcha that catches beginners: approving a PR does not automatically merge it. The merge is a separate action, and if merge checks are configured, the merge button will be disabled until all checks pass. Also, if you push new commits after someone has approved, some configurations will reset the approval, requiring the reviewer to re-approve. This behavior is configurable but often surprises teams that are new to Bitbucket.