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:
- Write code for FeatureA
- Create PR for FeatureA
- Wait for FeatureA to be merged to master (updating FeatureA as necessary)
- Write code for FeatureB
- 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?