Maybe have a look at this
https://trunkbaseddevelopment.com/
Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.
Fundamentally this all seems like a misreading of trunk-based development, though. The whole idea was to get away from old Subversion-style branching, where there would be long-lived branches running for sometimes several month. If you were a company that moved from svn -> git, trunk-based development was a way of communicating that branches were cheap and disposable, and merging was quick and easy.
So unless you have a ton of dependencies you wont notice much breakages from other teams.
No, in trunk-based development, you push to the trunk, aka master.
The difference is perhaps not that big; with TBD, you have a branch, but only on your machine, which you merge to master before pushing, whereas with the second workflow, you push your master, then merge somehow.
> their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?
I don't understand this. Of course you can and should run all tests locally.
If you follow the ops link there are multiple diagrams where that is not the case.
And
"The short-lived feature branch should only last a day or two and never diverge from the trunk enough so that a merge back is problematic. After the seal of approval from code reviewers and CI daemons, it should be merged back into the trunk. It should be deleted, as proof of convergence. The developer in question may then go ahead and make the next short-lived feature branch for the next story/task they’re doing" https://trunkbaseddevelopment.com/youre-doing-it-wrong/#dura...