Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,455,715
Community Members
 
Community Events
175
Community Groups

How do you track revisions on a pull request?

Edited

I'm trying to find a good workflow, and I don't know if there's a recommended way for this, or even a way to do this at all. (We're using the Forking Workflow, by the way).

Here's the scenario:

  • Bob makes a commit on his fork, and creates a pull request to the main repository.
  • Alice reviews his code and points out a couple of typos and style violations.
  • Bob makes the suggested changes and amends his commit, then does a push -f to his repository.

At this point, the pull request gets updated with the new commit, (the PR feed actually says "Bob removed commit ABC, and added commit XYZ"), and if Alice review it again, she will approve.

The problem is, there's no easy way for Alice to find out what changes Bob made to his code, and it's really hard to verify that all the comments have been addressed. On the other hand, I don't want Bob to add another commit just to fix a typo that hasn't made it to the main repository yet.

As I'm writing this, it occurs to me that perhaps the best course of action would be for Bob to fix the issues with a new commit, and once Alice approves the PR, to squash all the fixup commits into the main ones, and only then merge.

Is this the best way to handle the situation? Are there plugins that make the process more smooth? What do you do?

1 comment

 

The problem is, there's no easy way for Alice to find out what changes Bob made to his code, and it's really hard to verify that all the comments have been addressed. 

First subproblem: how to avoid re-reviewing a large PR if only some parts of that got updated by the new commit?

This is fairly simple because Bitbucket helps with it!

If you look at the "diff" view of the PR and click the files in the left-side tree control, then Bitbucket will automagically remember that you have seen the modifications in a given file. It turns the filename from bold to normal font weight. Then, if there is a new change on file "A", and you look at the diff again, then all other filenames will be displayed with normal font-weight, but "A" will be displayed in bold again!

In other words: only verify the changes in the files with bold filenames.

Second subproblem:  how to verify if all critics were handled?

We are very pragmatic with this. Add a marker (which can either be a TODO tag in the code or a Bitbucket comment on PR) and wait until the marker gets a confirmation (TODO tag gets removed or there is a reply to the comment) after that critic was handled.

It is dead simple.

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events