Use pull requests for code review

After you've added files and made updates to existing code, it's time to merge that code into your Bitbucket Cloud repository. Before you merge, you want to ensure that you maintain code quality and won't break already existing features. To get the feedback you need for code updates and improvements, you can create a pull request that includes all the lines of code you've added. Pull requests provide you with a method for requesting code reviews from your colleagues and checking build status based on your most recent commit.

To use pull requests, you need a branch or a fork, so you can develop your code on a separate branch (line) from the main code base. 

You can see how pull requests fit into a larger workflow example on the Workflow for Git feature branching help document.

Pull request process

Code review and collaboration are at the core of pull requests. Depending on your role, you may be an author, a reviewer, or both on one or more pull requests. The following is an illustration of how the end-to-end pull request process works.

Pull request authors

To find pull requests you've created, check the Your pull requests list on the Your work dashboard.

As a pull request author, the code review process officially begins after you create the pull request with reviewers. If you don't add reviewers during creation, you can always edit the pull request to add them afterwards.

After you've created a pull request and added reviewers, you might be inclined to take a break while you wait for approvals. However, as reviewers look at your code and make comments, you'll receive email notifications of the ongoing discussion in the pull request, giving you an opportunity to respond and making you become an active participant in the code review process.

Pull request reviewers

To find requests you've been asked to review, check the Pull requests to review list on the Your work dashboard. You can also go to the Pull requests page of your workspace's repositories to help your colleagues with other pull requests where you're not listed as a reviewer.

When a workspace member adds you as a reviewer, we'll notify you by email. After the initial notification about pull request creation, you'll continue to get email notifications for the following actions:

• The author makes updates

• Another user makes a comment

• Another reviewer approves

• Another user merges the pull request

To disable notifications, you can unwatch the pull request.

During your code review, you'll comment with feedback, suggestions, and ideas. You may take time to consider if there are any obvious logic errors, all cases are fully implemented, existing automated tests need to be rewritten, and the code conforms to existing style guidelines.

After your review, if the pull request is ready to be merged (or if you trust the author to resolve your tasks before merging), click the Approve button in the top right. A green checkmark appears next to your name in the Reviewers field after you approve a pull request.

Default Reviewers

You can configure your repository to automatically add predetermined users to all pull requests by setting up Default Reviewers in your Repository settings, which allows you to define a list of users that will always be added to all your pull requests. This can be useful, for example, when a repository has many contributors, but a single set of owners that wish to review any changes.

Another way to predetermine reviewers is by defining owners in a file that you create named CODEOWNERS located in a special configuration directory called .bitbucket. This file allows for fine-grained control over which reviewers are added to which pull requests by examining the files/directories that were changed in the source branch, and looking up the ownership rules in the CODEOWNERS file. For more details on setting up and using code owners, refer to the Set up and use code owners help document.