Question

I am resolving two issues simultaneously, but I want the reviewer to see my changes for each issue separately. I am thinking that if I create two pull requests (one for each issue), each issue will be easy to review.

My current guess is to create a separate branch for each issue, place my commits on each branch separately, then create a pull request for each branch. The reviewer can then see the changes pertaining to each issue, but will have to merge in each branch separately. None of my code for either issue will overlap, so merging each issue should not be a problem.

My other guess is to log which issue I am addressing in each of my commits and then create one pull request. The reviewer will have to parse my commits to see which issue I am addressing, but will only have to merge one branch. This is a simpler approach, but is it preferable?

Or is there an easier way to do this? Let me know if I can clarify anything.

Was it helpful?

Solution

Merging is easy.

Deciphering your intent is hard.

By keeping the work on the two issues separate you are allowing the reviewer to accept, reject, or ask for improvements on the issues independently.

If they were merged and you need to make a small change for one of them, both improvements are blocked until the change is made and reviewed.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top