We use feature branches and issue pull requests/code reviews from those feature branches in BitBucket and it's been a universally well received tool and definitely increased the quality of our code reviews and overall code base.
If the PR method works for your team, that's great. In my experience, it leads to more friction and the reasons to implement it are usually "best practices" articles like TFA, not actual needs of the team.
To avert chaos it's much better to have an orderly branching model in place e.g. feature branches! My fellow partners made us go all "git flow" last year and the result has been a really tidy and satisfying workflow:
http://nvie.com/posts/a-successful-git-branching-model/
Atlassian's SourceTree also helps us with maintaining "the flow":
https://www.atlassian.com/git/workflows
Git extensions and screencast on how to setup on OSX:
Similarly, hotfixes have metadata which goes to their own hotfix.csv file.
A deploy script processes the hotfixes and feature files to create a Release notes.
We've got a very smooth release documentation process which is difficult for Dev's to hate and skip.
However, feature branches are just multi-stage commits. Sure you can invest hours of your life setting up CI, then writing code, not testing it locally before pushing it to master, getting an obscure error from the test/deploy process, fixing it again, pushing again, getting another error, etc. But you probably want to, you know, ship the product.
Having said that, if your workflow actually resulted in you writing better code faster and you ended up shipping earlier and making more money, I'd love to read about it.
Maybe I've misunderstood, but why aren't you testing it locally? With trunk based development you make your changes, run a local build and push if it passes. Everyone (including any CI servers) runs the same build process.
The trick is that you have to be able to push to master without breaking it, which is scary to many developers and usually requires a shift in thinking. How do I do large refactorings? (you don't - do many small refactorings instead). How do I add a half-finished feature? (break the feature into many smaller features, use feature toggles, etc.)
Yes, there is always going to be a feedback delay between you making a change and the full impact of that change being known (even if your feature is bug free, will the customer want to use it?), but we should be bringing that feedback forward by moving changes through the pipeline as early as possible. Feature branching delays feedback, which is why I reject it.
The reason for trunk-based development over feature branches is that the time required to integrate a patch usually increases proportional to the square of the time since last integration. With trunk-based development, most commits reflect about 1-2 days worth of work, and they go in with minimal conflicts. Branches (and patches that sit idle for a month or two) often take forever to integrate, because as you are trying to update your code to the new master, the master is itself changing. At some point, the process doesn't converge, and you can spend forever trying to update a branch.
Perhaps this is just a terminology issue, but I strongly disagree with this. You can always merge/rebase the latest version of master into your feature branch.
...please?
However, if you have a team that is comfortable working this way -- and is only occasionally breaking things; it happens -- then it is a wonderfully creative, frictionless, and flexible way to develop.
Works well.
Break the build, all stops, and we huddle and fix it.
Sort of like the andon cord in toyota factories.
I think you're ascribing too much ceremony to this. It's useful to have something written down for any discussion about these changes, and a pull request is as good of a place as any for that. Plus it ensures everything is all set up to merge once you're both satisfied with the changes.