Think about how we can improve our interactions in the sometimes emotional world of software engineering. Do Pull Requests make sense in our modern way of working? How do they affect not just software quality but also our interactions with each other?
Having to review PRs is dreadful, as is chasing people to review PRs.
Many commentators doubt the Pull Request mechanism for a variety of reasons, all valid as far as I can see in a commercial context(*). For example, a PR always happens from a branch or a forked repo. Why would we branch at all if we’re looking to perform proper CI (Continuous Integration) every day? Many CI implementations only rebuild the main branch and perhaps only run once a day due to long running tests, flaky tests etc. By not integrating to main, and not testing our long lived feature branches, we risk a bigger bang of breakage on merging further down the line.
Branches would have to be short lived (less than a day) so you might as well just check-in to main? i.e. Trunk Based Development.
The other side effect of ‘early merging’ (or making sure we do proper CI) is that our interactions with each other around merging and our communication needs to be way better. So we need to work at it, but it’s preferable to just shooting in a PR.
About ten years ago I was working in a small, high-performing team, building business rules ETL transformations for a bank. Many changes were need to core code and our source control was unsophisticated but effective. We had no branches, we just kept informing each other of the changes. Didn’t always work but our integration tests ran regularly on the whole product. Also we all knew when breaking changes were on the horizon.
Don’t overcomplicate your branching strategy just because the tools almost enforce it for you or you decided gitflow or even github flow was the way. Pull Requests cause friction both in our integration strategy and in our working relationships.
If you don’t need to do it, then don’t do it.
* – for open-source projects or projects that are more asynchronous in nature, PRs and forked repos/branches make a lot more sense.