Workflow and process when branches have dependencies in git for code reviews

Question

A fairly common workflow for working with git is:

• Fork master
• Make changes/add functionality in branch
• Make pull request for your branch vs master
• Merge pull request (after code review, automated tests, whatever)

It is also possible to run this in parallel to another fork - perhaps you are adding FeatureB and simultaneously making a patch fix to FeatureA, you can have two separate branches both based on the master branch.

This works well when you have an established project, where you can work on independent pieces more easily. However, when you have a project that is less established (perhaps it is a new project or horribly brittle) it is likely that you may have FeatureA and then base FeatureB off FeatureA.

If you have a code review process, this means you have something like:

1. Write code for FeatureA
2. Create PR for FeatureA
3. Wait for FeatureA to be merged to master (updating FeatureA as necessary)
4. Write code for FeatureB
5. Create PR for FeatureB

Depending on the turnaround time, step (3) might take a while - so it's likely that you would start on step (4) and make (3)/(4) happen at the same time. You may even be ready for (5) to happen.

The problem is you are either writing additional code which depends on non-reviewed functionality OR are not working on anything until the code review processes FeatureA. And potentially ready to make a PR for FeatureB before its dependent PR is merged.

There are some possibilities to resolve this (do a PR against FeatureA's branch, wait for the FeatureA's PR to continue, keep updating the FeatureA PR).

What is a good workflow to manage the difficulties associated with dependent pull requests?

Answer 1

You have to weigh the risks associated with the dependency, but I'd say that you can afford to work on B as soon as possible and propagate any changes made in A into B when necessary.

• If the pull request for A is accepted (code builds, etc.), everything is fine. On average, you should encounter that case more often than not.
• Otherwise, what could happen? In the worst case, A is completely broken and should be deleted: that means that you should rework B more deeply or drop it. But more realistically, you need to edit and fix minor things in A. And if so, you can merge it to branch B.

If branch A changes too much too often, it is not a good idea to base branch B on it.