Stash is now known as Bitbucket Server.
See the

Unknown macro: {spacejump}

of this page, or visit the Bitbucket Server documentation home page.

Pull requests in Stash provide the team with a quick and easy way to review changes made on a branch, discuss those changes, and make further modifications before the branch is merged to master or your main development branch.

On this page:

Creating a pull request

When you are ready to start a discussion about your code changes, simply create a pull request.

To create a pull request:

  1. You've pushed your changes to Stash, right?
  2. Now, go to the repository in Stash. Either click Create pull request in the sidebar, or choose Compare from the Actions menu (when on the Source, Commits or Branches pages):


     
  3. Choose the source and destination branches. The source branch is where you made your code changes and the destination is the branch you want to merge to. The source and target branches may be located in different forks:


     
  4. Use the Diff and Commits tabs (see below) to compare the source and destination branches, before creating the pull request.
  5. Click either Create pull request, or Continue, and enter a title and description that will help people understand what your pull request is about. You can use mentions (to notify another Stash user), and markdown (to add formatting) in your description.
  6. Add reviewers – they will receive a notification by email. Other people who have permissions on the project can participate in the discussion if it interests them.
  7. Click Create.

You will receive email notifications when your reviewers and other participants comment on the pull request, or commit changes to it.

Editing a pull request

After creating a pull request, you can modify it by clicking Edit on the pull request's page. You can edit details such as the TitleDescription and the Reviewers. In particular, you can change the Destination branch for the pull request – you'll need Read permission on the branch you want to set.

Discussing a pull request

The most important thing about a pull request is the discussion that it generates. With Stash, you can comment on the pull request as a whole, a particular file, and on specific lines of code in a file. Comment likes are a quick way of amplifying review feedback – effectively saying "also consider this person's feedback". Furthermore, you can attach a task to any comment, so actions identified during the review can be easily tracked and resolved. Read more about pull request tasks below.

To see all the pull requests for a repository, simply click Pull requests in the left-hand navigation panel (when viewing the repository).

To help you contribute to the discussion, Stash organises all the information about the pull request into 3 tabs: Overview, Diff and Commits:

Overview

The Overview tab captures all of the team's activity on the pull request in one place, right from the initial creation, through to when it is finally merged (or declined), with all the comments, replies and commits that happen along the way.

You can add a comment on the Overview tab (just under 'Activity'), or reply to a previous comment. Use mentions to alert another Stash user to your comment, and use markdown to add formatting, for example headings or lists.

Diff

Diffs for Stash pull requests provide the following advantages:

  • The diff highlights the changes that will result when the merge occurs, so you can see exactly what the effect of the merge will be.
  • The file tree on the left colour-codes files that have been added, changed or deleted, so you can quickly see the files you may need to review.
  • As you'd expect, the diff for a file shows which lines of code have been added, deleted or modified.
  • You can comment on the whole file by clicking the icon on the right in the diff header.
  • You can comment directly on a line of code right in the diff, by hovering over the line, clicking the icon at the left, and entering your comment. Your comment will also appear in the activity.
  • Comments in the diff are threaded, to allow meaningful and contextual conversations about your code.
  • The Side-by-side diff option from the Action menu (arrowed below) lets you easily compare the changes that will be merged. Use the N (next) and P (previous) keyboard shortcuts to move between hunks in a diff. Use Shift+N (next) and Shift+P (previous) to move between comments in a diff. The 'map' in each margin of the side-by-side diff provides a visual summary of the diff hunks, and indicates which part of the file you're currently viewing:

  • Search across all the files in a pull request, when viewing a pull request diff.

    The search looks at the diff and surrounding code lines to provide context. The file tree on the left displays only the files returned by the search.

    Use the F keyboard shortcut to quickly access code search when viewing a diff in a pull request. The usual J (next) and K (previous) Stash shortcuts let you move between files in the search results. 'Esc' cancels the search.

Commits

The Commits tab lists all the commits that will get merged (those that are greyed out have already been merged). Clicking through to a commit takes you out of the pull request context. 

When viewing a commit you can comment on the whole file, or a particular line of code, just as for a diff, for any file in the commit.

Participants can commit new changes to the branch. Stash auto-updates the Commits tab of the pull request, so you can see exactly which commits will be merged. Stash is smart about comments, moving them along when lines are added or removed. If a line with a comment gets removed, you can still view the comment in the activity, but Stash marks the diff as outdated to let you know that this piece of code has been changed in recent commits.

Pull request tasks

You can attach one or more tasks to any pull request comment, to track required work identified during a review.

Try highlighting some text in the comment, then clicking Create task – the task is automatically created and saved with that text.

When that task is done, simply check the box for the task.

To see all the unresolved tasks for a pull request, use Shift+T when viewing the pull request:

Click the 'link' icon for a task to see the task in the context of the comment and source code.

Note that:

  • Anyone with permission to browse a pull request can create a task on any comment, and can browse, resolve and reopen existing tasks in the pull request.
  • Repository admins and pull request authors can edit and delete any task in the pull request. Reviewers and others can only edit or delete their own tasks.
  • A Stash administrator can set a merge check that requires all tasks to be resolved before the pull request can be merged. See Checks for merging pull requests.


JIRA issues integration

When Stash is integrated with JIRA you can see the related JIRA issues right in the pull request.  You'll see either the JIRA issue key, when there is just one, or the number of related issues:

Click an issue key to see details of the issue, such as the description, status and assignee, without having to leave Stash:

Within the JIRA Issues view, click the issue key in the breadcrumb to see the issue in JIRA. This allows reviewers to gain important insight into the task that is being worked on, by seeing the comments and attachments on the issue. This also gives access into JIRA, so you can easily keep issues updated.

See JIRA integration for a description of all the integrations you get when Stash is linked with JIRA.


Merging a pull request

Once you are ready to merge a pull request, and when the reviewers have approved it, click Merge at the top right of the pull request view. You can merge a pull request if you have write (or admin) permission on the project.

Stash does not enforce particular review workflows, so anyone with write permission on the repository can merge a pull request, including the person who opened it. This flexibilty allows different teams to have different approaches to using Stash. If your team requires stricter control, consider using branch permissions to restrict who can merge a pull request to particular users or groups. You might also want to consider using a plugin to enforce a particular workflow, for example to ensure that only approvals from members of your review team allow merging. See Checks for merging pull requests.

 

In the 'Merge Pull Request' dialog, you can add extra information about the pull request: 

The text you add appears between the subject line and the log lines that Stash and Git generate.

Check Delete source branch after merging if you no longer need that branch in the repository. Stash checks on a few things before allowing the deletion – the branch being merged will not be deleted if:

  • The branch is the default repository branch.
  • The user does not have permission to delete the branch.
  • The branch is subject to an open pull request.

 

Once accepted, the pull request is marked as merged on the Pull requests tab.

If Stash detects a conflict that prevents the merge, notifications are displayed on the Overview and Diff tabs of the pull request. Click More information to see instructions for how to resolve the conflict in your local repository.

Watching and notifications

You automatically get added as a watcher of a pull request when you are added to the pull request as a reviewer, or when you perform an action related to the pull request (such as adding a comment):

ActionYou are added as a watcher
You are added as a reviewer(tick)
You comment on a pull request(tick)
You reply to a comment(tick)
You push to the source branch(tick)
You approve the pull request
(tick)

You can manually add yourself as a watcher by clicking the Watch button on the pull request screen.

You can always stop watching a pull request by clicking the link in the email notification, or the Unwatch button on the pull request screen. If you stop watching a pull request you will not automatically be added as a watcher again if you subsequently perform an action that would otherwise have added you.

Stash sends email notifications to watchers when certain pull request events occur. By default, email notifications are batched, but you can change your personal account settings (on the Notification settings tab) so that you get notifications immediately. Note that notifications are always sent immediately:

  • To the reviewers when a pull request is created.
  • To a user when they are added as a reviewer to a pull request.
  • To a user when they are mentioned in the description of a pull request.

See Notifications for details.

  • No labels