nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

New in Bitbucket: Focus on recent code changes with iterative review

Dave Parrish [Atlassian]

This feature update was also posted on the Bitbucket blog.

Hello, Bitbucket Cloud Community! 👋

We are incredibly excited to announce the introduction of Iterative review, a feature designed to help your team get pull requests completed faster by removing the need to re-review code you’ve already seen. Now when an author pushes new commits based on your pull request (PR) feedback, you’ll have the option to focus on just those new changes.

How it works

Any time you finish reviewing a pull request, Bitbucket will make a note of the last commit you viewed. For purposes of this feature, here are the different actions that constitute “reviewing”:

Approving the PR
Requesting changes
Marking all files as viewed
Submitting batched comments (with or without approval status)

When the author makes new commits to the PR, you’ll then have the option to view just the changes made since your last review. This is possible thanks to a new dropdown on the “Files changed” tab that controls your diff view for the pull request.

By default this dropdown will be set to “All changes”, meaning you’ll be looking at the full changeset on the source branch. This is the view that we’ve always shown on pull requests. When you switch the dropdown to “Changes since last review”, we’ll show you just the files changed in the commit(s) since you last reviewed the PR. The number next to “Files changed” will update to reflect the number of files you’re viewing.

The “Changes since last review” option will only appear when a PR has new commits that you haven’t seen. Remember that your last-reviewed commit is specific to you as a user, so your teammates may see a different view of the PR, depending on how much of it they’ve already reviewed.

At any time during a pull request, you can also select an arbitrary commit (or range of commits) in the dropdown, allowing you to focus on any part of the PR’s history.

Things to consider

We will always default you to “All changes” mode – the incumbent functionality on pull requests up to now – but we think you’ll find iterative review to be useful in many situations. The ability to look at just a slice of a pull request is a powerful feature, and it may take some getting used to. Here are some important considerations when using iterative review:

When you are looking at a PR in “Changes since last review” mode (or with a custom diff range selected), any comments you make will be associated with that diff range. Other PR viewers will be able to access these comments from the activity feed or by using the comment navigation dropdown.
We don’t currently support showing “Changes since last review” if a PR has had a merge commit or destructive force push since your last review.

Learn more about pull request review

Available today on your Bitbucket workspace

Iterative review is available today for all teams using Bitbucket Cloud. As always, please feel free to share your thoughts with us through the help '?' menu > Give feedback.

Comments

patrick_abenv0

This new UI is terrible. Old UI was significantly better. Not defaulting to files changed tab must have been a decision by someone who has never done a PR review in their life. No one cares about activity on a PR. Only the most recent changes at time of review are important, and that is available only on the files changed tab.

Neal at Fresh

I just encountered this new feature and I like it. I was actually wishing I had this last week when I was reviewing PRs that had been changed after I requested changes.

Richard Stehlik_yls5ez

@patrick "No one cares about activity on a PR". Actually the PR author does. As an author I want to see the most recent comments by the reviewer and the related code. I don't want to scroll through the whole PR looking for reviewer comments.

Murph_7pbi2k

The header that contains the tabs is hidden when scrolling instead of being anchored to the top of the screen. So when I scroll down reading a PR, and want to switch over to the overview, I have to scroll all the way up manually which is a terrible UX. Thankfully they added 1,2,3 shortcuts to navigate tabs.

Michał Fastyn_bxd8y2

@Dave Parrish [Atlassian]
This change is really awesome.

Still, alfter some time of getting use to, my opinion about new layout is the same -> previous was superior. New one has many issues mentioned in this thread. Clickfest, scrollfest, less space, hard to read feed, dissapearing global comments, code pushed to the right side of screen.

Tim_ozntpk

Thank goodness it's finally possible to comment on a commit (at least partially)

Given I navigate to a specific commit
When I comment on a specific line
Then the comment now displays in Activity 🙌
But the comment is not displayed when viewing Files Changed: All Changes 😔
(even though the line is still present in the combined change)

Really missing keyboard shortcuts to navigate next/previous commits.

Dinesh Codhadu

@Dave Parrish [Atlassian] The while the continuous updates and improvements to UX are welcome, it would seem that the UX is mostly designed for large screens, can you please also consider changes that optimize the minimal screen real-estate on smaller laptop screens?

Another feature that can be helpful is a way to direct-link specific files in description or comments? so that we can navigate to the specific file highlighted directly?

Alex Oren

“Changes since last review” is always greyed-out for me.

I would love to use the feature, but it just doesn't work!

unknown

I think for the PR author, it would make sense to look at the history tab, but for Reviewers, I would like to see the File Changed tab as the default.

Enrico Scholz_bdo13e

limiting to "non-destructive" operations makes the current implementation pretty useless. It is common practice that pull requests are fixed by a rebase. Especially when working with review chains (feature/A -> feature/B -> feature/C)

Reviews with bitbucket are really frustrating:

- when author changes something, you do not see what has been changed and review must be done from the beginning again

- comments in commits are allowed and for me, it is the native way for doing reviews. Unfortunately, these commits are well hidden and disappear when PR is updated

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bitbucket

bitbucket-cloud

pull-request

code-review