Code review without a pull request

[Ahsan Uddin]

Hi,

So I understand that once I open a pull request, I automatically get a code review for the code that's about to be merged, that's great! But is there a a way to create a Code review without creating a Pull Request? For example, let's say I am working on a feature and I would like to do a code review with peers, but I don't want to do a Pull Request as the feature is still Work In Progress.

I understand that I can use the "compare" feature in BitBucket to see the code diff, but I needed the "Codereview" kind of feature explicitly so that I can:

1. Share the code review link with my peers so that they can see it   
2. They can comment and open "tasks" on the code

...and all of it while not creating a Pull Request. Is that possible? 

Thanks!

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

In Bitbucket, you need to have a pull request to do the code review. The code can still be in work in progress and the PR will be updated as soon as you push more code to the source branch, if that is okay for you.

And you can even see the difference since the last review, if you want to see only the latest changes. This is very useful if you keep the PR open until the feature is fully ready.

The only way to get away from PRs is probably to consider "Crucible" - Atlassian's code review tool. Unless, of course, you develop an add-on for Bitbucket!

[Ahsan Uddin]

Thanks a lot, Jobin! Yeah unfortunately the features that I am creating won't be pushed into the main branches as its just for fast prototyping purposes. So going through a PR is still not optimum in my case. 

Anyway, now that you have mentioned "Crucible" let me take a look at it.

Thanks!

[Alex Oren]

The problem with Jobin's suggestion above is that it does not work when the code review is performed on one branch but needs to be merged to another.

Consider this situation:

• developer-A is working on feature-A on their dev-branch-A (branched from master)
• developer-B is working on feature-B on their dev-branch-B (branched from dev-branch-A, because it uses its functionality)
• developer-B wants to have their code reviewed, but only the changes in dev-branch-B vs dev-branch-A
• *After* dev-branch-A gets merged to master, developer-B will create a PR of dev-branch-B to master
• Creating a PR of dev-branch-B into dev-branch-A risks the possibility of the PR being merged into that branch, which is unwanted.