pull request workflow newbe question

[Scott Ocamb]

I am working to understands the workflow for pull requests. Here is what I have discovered along with questions. If this could be validated, it would be appreciated.

1. A developer needs to make a change. She creates a branch for the change "My-Change"
2. The developer makes the change in the My-Change branch. When she is done, she creates a Pull Request and specifies the destination branch for the change. Any necessary comments are also added.
3. The Reop Owner gets the pull request. All changed files are available for in line comment as well as global Comments.
4. If all is well, the request is approved and merged. 

My questions and possible misunderstanding happen if there are any cycle updates because of the review.

It seems after a request is declined, it's life ends. The developer would need to submit another request for the review to continue.

It also seems that the files changed in the review appear only once. Here we have the opportunity to comment on lines of code, but where there is a code review change cycle, the changed files are not available in a single request.

If this is true, thenb any code review cycle that involves remediation because of the review will require multiple declines and subsequent requests.

Am i close? Any feedback would be appreciated as i work to understand this tool.

[Scott Ocamb]

Thanks for the response. I did think of that. From what I can see, the files that are changed by the second and later updates by the developer do not appear in the individual pull request UI.

This means that the reviewers must manually go and look up the files that changed. Also, there no way to comment on individual lines of code. I really like that capability.

Is this correct or am I missing something?

Thanks again for your help.

[jredmond]

Hi Scott,

You're right that the "decline" option kills pull requests forever. Bitbucket automatically updates open pull requests with new commits, though, so if the reviewers leave the pull request open through several commits then the pull request will show all net changes. 

With that in mind, I'd suggest a slightly different approach to the code review:

1. Dev branches, makes changes, commits, pushes, etc. as before
2. Reviewer sees that the pull request is not yet ready, and leaves comments with suggestions
3. Dev sees the comments, makes appropriate changes, and pushes new commits
4. Reviewer looks at the updated pull request. If everything is ready now, reviewer clicks "approve"; if things still need work, reviewer comments again and the cycle repeats
5. Once the team's review requirements are satisfied, someone clicks "merge", and the source branch is merged back to the destination branch.

With this approach, the pull request remains open for the duration of the review process. You'd save "decline" for things which will never, ever happen.

Does that help?