Usually when feature-branch-1 is still under review and feature 2 relies on feature 1, I just open a PR from feature-branch-2 onto feature-branch-1 to get the review process started, knowing that feature-branch-1 might still change which I can deal with by rebasing.
I came from Airbnb (vanilla github) and some friends converted me to a stacked workflow. I think the challenge with vanilla git is that rebasing and re-pushing becomes a brutal process if you stack 3+ changes. (At facebook people regularly stack over 10). Beyond recursive rebases, Github offers no support for navigating your stack, merging in a stack of approved PRs together, adjusting merge bases, etc.
Most of these practices are just inspired by what Phabricator and a few of the big companies are already doing well :)
Glue code is pretty easily split up into a stack. 90% of what I’ve worked on has been glue code.
To ship your change you need to update what’s there already. Tool A needs an integration point. Tool B needs a hook added. Tool C finally joins A to B.
Implementing the bits for A and B found two useful refactorings in each codebase. At the end of it all there was also some dead code.
That’s 8 commits. The downside is you end up yak shaving a lot.
You have to fix a lot of merge conflicts. I used this workflow at AWS -- code reviews can take some time, you're writing a lot of code, and you want your CRs to be small.
If someone leaves a comment on the CR for the first branch you fix the issue and rebase. It's not fun, but this is the only effective way to do it (that I know of).
You can't open a PR in the parent repository against a branch in the fork. You can create that PR inside the forked repository, but that doesn't allow the maintainers of the parent repository to do anything with it. So if you've got two stacked branch in a fork, you can't open two PRs for them in the manner GP described.
