The common approach people attempt to follow is creating a branch for the inner most dependency, and then a branch on top of that branch for the next dependency up, and so on and so forth until they get back up to the top most layer of the architecture.
This approach fails for a number of reasons.
You don't generally know what the inner most layer is until you have driven it out by doing outside in development. There is a lot of overhead in managing moving the non lowest layer changes up to branches above this branch, and so on and so forth up the stack.
Making changes to lower or even the lowest layer of your stack requires a huge amount of overhead in branch management to effectively range rebase each of the branches on top each other one by one.
So if you goal is create small, isolated, logically chunked pull requests. This workflow & the concepts involved are the only workflow I have found thus far that is fluid and doesn't have massive overhead that creates tension around following the best practices.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The common approach people attempt to follow is creating a branch for the inner most dependency, and then a branch on top of that branch for the next dependency up, and so on and so forth until they get back up to the top most layer of the architecture.
This approach fails for a number of reasons.
So if you goal is create small, isolated, logically chunked pull requests. This workflow & the concepts involved are the only workflow I have found thus far that is fluid and doesn't have massive overhead that creates tension around following the best practices.