https://trunkbaseddevelopment.com/
The heart of this being this point: sometimes the workflow of the team demands different ways of thinking about it, and its nice to have that flexibility.
Edit: worth noting also, this does something for those of us using this methodology (I am a big promoter of trunk based development with ruthless purging of short lived feature branches)
Opening WIP PR allows everyone to see several things:
1. what issue is being worked on 2. that it is claimed by someone 3. When that issue was started to being worked on 4. The intentions in solving the issue (if done right)
Those are real wins.
I wonder if the hub client will get a open draft PR option soon.
If so, this can't be done within git, since the overall container is a single repo.[1] There is no atomicity or even coordination between repos. You can get loose coordination though via integration with an issue tracker like jira. The tracker links multiple PRs across multiple repos into a single meta-merge. But you aren't going to get "simultaneous merge" in the sense of a single atomic cross-PR and cross-repo commit.
[1] One of the things that is awful with github [not git itself], is that all your controls such as commit rules, privileges, visibility, have the granularity of the entire repo. Even though awful, this is the right approach considering that many git restrictions are per-repo, eg branches. vs perforce, eg
This is one of the reasons cited for monorepos, you can make a single atomic commit/PR that changes some API, and the consumers of that API.
As it is now, you end up writing a warning comment to merge some other PR at the same time and hoping your reviewers read it.