多个分支的合并顺序

Question

I'm having some trouble figuring out the best order of merging branches to avoid merge conflicts and easier code reviews. I'm going to use the following picture to diagram my situation.

As you can see, I made Branch V from master, and added some commits. Then I also have Branch K which was branched off of Branch V, and also has some commits. I want to have two merge requests up for people to review, so my original plan was to have Branch K set to merge into Branch V, and then Branch V to merge into master.

Is that the best strategy? I didn't want to set Branch K to merge into master, because in the code review, the diff between Branch K and master includes differences that were made Branch V's commits.

I just really want to know what the best merge order is. Thanks!

Answer 1

Yes, making one PR from V to master and another from K to V makes the most sense from the point of view of making those PRs easy to review , as each PR will only show its relevant code changes. And I would argue that making life easier on reviewers should be your top priority.

Once these PRs are approved for merge you could either:

1. first merge K -> V and then V -> master
2. first merge K -> master and then change the base of the other PR to master and merge it as well

for option 2. to work well, K needs to make sense on its own, because you shouldn't at any point merge something broken into master

if you choose option 1. I would also suggest to edit the V -> master PR description after the merge of K to reflect that it now holds more (approved) changes

and in general I would suggest to use the PR description to describe the relation between the two PRs in order to give the reviewers the full picture