[Author: Jonathan Frankel]

This article is taken almost direct from Atlassian's Working with pull requests. Some modifications were fabricated to the layout.

Pull requests are a elementary and effective mode to do code review and collaboration in a shared environment with little friction in your team.

Pull requests give y'all:

  • Complete unequal (difference) of the changes to each file.
  • Automatic updates then y'all tin see changes as they are made.
  • Inline comments and so you can pinpoint change suggestions.
  • Tasks to help y'all keep track of what changes need attending.
  • Notifications for comments, commits, or approvals.

Building better pull requests

Hither are a few suggestions to make pull requests more than effective:

  • Try to brand the pull request small plenty to review just large enough to give you the context of the feature, bug set, or update.
  • Utilise @mentions and in-line comments to guide specific reviewers to specific items in the lawmaking.
  • Ask reviewers to create Tasks for things which must be addressed for blessing. This helps designate between suggestions and discussions and things which must be fixed.
  • An accurate description and links to any issues gives reviewers more than context and better access to what they demand to empathize the problem or characteristic y'all're addressing.

Create a pull request

  1. Click Create pull asking.
  2. Select the branch with the changes you want to merge.
  3. Check the destination repository and branch.
  4. Add together a title that tin be easily recognized in notifications and the pull request list.
  • Source: This is the source commit, branch, or fork yous are merging. You cannot alter the repository of the source but you tin modify the branch so check to be sure you're merging the correct branch.
  • Destination: This is the repository, branch, or fork you are merging your change into. You can modify the path for both the repository and the branch.
  • Title and Description: This will be the display title in the pull asking list and in notifications.
  • Reviewers: Pretty much describes itself. You lot can also apply @Mentions in comments to get someone to look at just 1 specific piece of code just non be responsible for reviewing the whole pull asking.
  • Shut branch: When you select this the source co-operative will be closed automatically once the pull asking is merged. The closed branch will no longer appear in your list of branches in Bitbucket.
  • Diff and Commits:
    • Diffs: Shows a comparing of the changes in your pull request to the files in the destination branch.
    • Commits: displays a listing of all the relevant commits. This list will be updated with any commits to the files on the source branch until the pull asking is either merged or declined.

Add reviewers to your pull asking

Select reviewers for this pull asking to make key contributors aware of the changes and create an constructive review. Every reviewer can comment on the pull request and with a single click give their blessing. If changes are fabricated to the code, they can meet those changes as soon equally the new commit is made. Additionally, the contributors you invite tin decide to stop watching the pull request with a simple click. Add together reviewers to the pull request when you create information technology by entering their Bitbucket username or email address to the Reviewers department of the page. Add reviewers to the pull asking after it is in progress by clicking Edit button (between Merge and Decline) at the elevation of the request.

Compare before issuing a request

Before creating a pull asking, you should compare your outgoing requests to the destination repository. This tells you how much the destination repository inverse while you worked on your fork or co-operative. You exercise this by comparison incoming changes.Information technology is good practice to brand sure that there are no incoming changes before you make your pull request. If there are changes what do you do? Information technology depends on your projection workflow. For instance, if you lot are working on a team your projection workflow might require yous to merge and test incoming changes before sending your outgoing changes back to the destination. To compare your source to the destination, exercise the following:

  1. Navigate to the repository with the changes.
  2. Press the Compare button.
    The arrangement displays the Compare page.
  3. Adjust the Source and Destination values so they match the pull request yous anticipate making.
  4. Press Incoming to see how the destination has changed since you've been working.
    If in that location were no changes on the destination repository, the dialog reports:
    There are no changes.
    If there are changes, the system provides you lot with some helpful tips for merging them into your local repository.

Asking the destination repo possessor pull your changes

To create a pull request, do the following:

  1. Navigate to the repository with the changes.
  2. Press the Pull Asking push button.
    The system displays the request class.
  3. Complete the course as advisable for your request.
  4. Press Create pull request.
    The organisation opens your latest request on the Pull Asking page of the original repository.
    To see the listing of all the pull requests against this repository, you can click Pull Requests in the navigation bar.
  5. Adjust the Source branch if necessary.
  6. Suit the Destination repository or branch if necessary.
  7. Enter a Title and Description for your pull request.
  8. Press Create pull asking.

Take a pull request

Only a user with write permissions on the destination repository tin can accept or reject a pull request. Whatsoever user with read permission in a repository can review the open up, accepted and rejected pull requests. The following procedure illustrates the steps in accepting a pull request:

  1. Go to your repository.
  2. Click Pull Requests in the navigation bar.
    A list of incoming pull requests under the Open context.
  3. Click a pull request on the list.
    The pull request details announced and the view defaults to the Diff context. Y'all tin can also view the Commits or the comment Action on the asking.
  4. Examine the request using the various contexts..
  5. If you determine that you want to merge the fork into your own repository, click Merge.
  6. Confirm the activity if prompted. Bitbucket merges the changes into your repository, all on the Bitbucket server.

Merge a pull request

Merging your changes is the final stage of the pull request process. Complete the post-obit steps to merge a pull asking:

  1. Click the Merge button. You'll run across something similar to the post-obit screenshot.
  2. (Optional) Update the Commit message with more than details.
  3. Select a Merge strategy from the two options:
  • Merge commit — Keeps all commits from your source branch and makes them part of the destination co-operative.
    This option is the same equally inbound git merge --no-ff in the control line.
  • Squash — Combines your commits when you merge the source branch into the destination co-operative.
    This option is the same as entering git merge --squash in the control line.
    For more details on these ii types of merge strategies, refer to the residual of this section.
  1. (Optional) If you're merging two branches in the same repository, you tin select the Close source branch checkbox to remove the branch from the list of repository branches.
  2. Click the Merge button.
Merge strategies
When to do a merge commit

Select Merge commit when yous want to maintain an exact history of changes. Merge commits are also useful if, every bit part of your workflow, pull requests are big in scope and yous review commits individually. Considering this strategy keeps all commits during the merge, you lot'll still see all commits from the source branch on the Commits page.

When to do a squash merge

Select Squash to make your commits listing less cluttered, which results in less time to search for commits that introduce a problems (with a git bifurcate) and provides an piece of cake-to-follow commit history. Because this strategy combines all commits when you merge, you'll simply run into one commit on the destination branch on the Commits page.

Turn down a pull request

Declining a pull request is the same every bit maxim you don't want to e'er merge the changes in that pull request in their current land. Any reviewer can refuse a pull asking and so your squad might want to establish a policy near when to decline verses when to leave the pull asking open in a stagnant state. Declining a pull request cannot be undone. In one case yous decline a pull request you will have to open up a new pull request request to continue a review. Declining a pull request has no result on the branches (source or destination) and then the changes in the source co-operative are nevertheless in that source branch.
To pass up a pull request navigate to the pull asking and click the Pass up button in the pinnacle left of the folio.
To view a declined pull request:

  1. Navigate to the repository with the pull request.
  2. Click Pull requests in the left hand navigation.
  3. Click Declined.
  4. Select the declined pull request yous want to view. The comments and tasks in a pull request are preserved later on it is declined. You can add together more than comments to a declined pull request, however, new changes pushed to the branch will no longer update the pull request.

Resolve a pull request with conflicts

When it detects conflicts in a pull asking'due south incoming code, Bitbucket cannot automatically accept and merge. If this happens, Bitbucket notifies you and instructs yous how to go along when y'all click Merge:

To resolve these kinds of conflicts you lot pull the changes to your local repository and resolve them there.

Manually merge pull requests locally

Sometimes information technology is a good thought to utilize a workflow where you test a changeset on your local system before accepting a pull request. You can do this with any pull request. The typical workflow is this: Receive a pull asking in Bitbucket. Update your local repository with the incoming changeset. Investigate and/or test the alter prepare. If you the change gear up is good, you merge information technology into your local repository. Yous may take to resolve some conflicts. Then, y'all button the local repository back to Bitbucket. Back on Bitbucket, the pull request is marked as accepted in the Pull requests tab. If you don't like the change request, y'all discard the changes locally and reject the pull request on Bitbucket.

Git command line example

This is a simple Git case of the procedure for pulling changes made by another user from a fork of a Bitbucket repository, back into the original repository also on Bitbucket. Check for incoming changes (ane alter detected).

              $ git fetch && git log ..origin/master   Password:   commit 2f41d64e75f2b4f0405cbfb1d2f882882809c209   Author: ANDREW <alui@atlassian.com>   Engagement: Thu Sep eight 11:50:08 2011 +grand   adding images

Check for outgoing changes (no changes detected).

              $ git fetch && git log origin/master..   Countersign:   remote: Counting objects: 6, done.   remote: Compressing objects: 100% (3/3), done.   remote: Total four (delta 1), reused 0 (delta 0)   Unpacking objects: 100% (4/4), done.   From https://staging.bitbucket.org/alui/alui-git    2f41d64..7e28ddb master -> origin/master   Pull the changes into the local repository.                          
              $ git pull   Password:   Updating 2f41d64..7e28ddb   Fast-forward     Thumbs.db | Bin 0 -> 11776 bytes     file.txt | 4 +++-     2 files inverse, three insertions(+), one deletions(-)     create mode 100644 Thumbs.db

Cheque the build condition on a pull request

If your vendor or build system runs a build when you make a commit, you can see the condition of the build(s) on each commit.
After you create a pull request, its Overview tab includes the build condition for all the commits on that pull request. Click the Commits tab to see the builds statuses separated by commits. — Image goes here build_status_pr The Builds cavalcade contains one of these statuses:

From the Commit column, click the link to the commit that you want to encounter. On the correct side of the commit page, you encounter the build status icon again and a link to more than details. Click the link to see details of each build for the commit. The table that opens when you click a build condition includes merely the most contempo status for each build, not a history of builds for the commit.

You tin can too bank check the build statuses for a repository without creating a pull asking. To come across the build status on a commit, printing Commits on the left side of the repository.