How do you review changes of MR that depends on other MR being merged?

Question

I am starting to work with other developers on a project where I have mostly worked alone up until now.

Our repo is hosted on GitLab and I am trying to figure out how to setup a simple git workflow for the team.

We have a master branch with the code that goes to production and I would like team members to work on feature branches that then get merged onto master.

For now, when one wants to resolve an Issue, it creates a Merge Request with a branch and pushes code to it. When it's ready they ask for review, and if the review passes I merge the feature branch to master. So far, so good.

The problem I can't solve right now is: if a team member wants to continue working on another issue that depends on a previous issue being merged, how can I review the code of the dependent merge request?

In this case, we would have a master branch, a issue-1 branch based on master and an issue-2 branch based on issue-1.

If the target of both merge requests is master, when reviewing the changes of issue-2 I would also have to sift through the changes of issue-1, which I should have already reviewed separately on issue-1 merge request.

Is it possible to keep master as the target branch for both MRs but use issue-1 as the base for the diffs of issue-2?

I know there's a Merge dependency premium feature, but I don't think it solves this particular problem.

Thank you in advance for your help.

Answer 1

In this case, we would have a master branch, a issue-1 branch based on master and an issue-2 branch based on issue-1.

A branch to be submitted as a merge request cannot be based on another branch to be submitted as a merge request.

The person working on issue-2 can certainly branch it from issue-1 in order not to have to copy those commits, but then issue-2 must later be rebased onto master, and this must be done with exquisite timing — namely, after issue-1 has been merged to master but before final submission of issue-2 for approval.

It would be better, however, not to do that. If issue-2 truly depends on issue-1 they should never have been different branches / merge requests in the first place. In general, merge request branches need ideally to be "orthogonal", i.e. they should do completely independent things to master.