Awesome PR processes in 7 easy steps

The anatomy of a PR: It has a an author, a title, and a summary.

In this article I’ll describe some patterns I’ve noticed that help to make the pull request (PR) process smooth and productive.

№ 1: Keep changes minimal

It’s easier to review one file than ten. It’s easier to review 30 lines of code than 300.

But it’s not only that. If you make many unrelated changes, it’s hard for reviewers to wrap their head around those changes. Why did you do them? Why are they necessary?

Even worse: Every single change might be something to discuss.

For this reason, it’s helpful to only do stylistic changes in lines that you have to touch anyway. If you notice an issue on your way, rather open another PR to fix that issue.

One way to reduce PR sizes quite a lot is to make a separate PR with tests that should already succeed. Maybe the behavior was changed just slightly and one of your tests would look almost the same for an old version. Then you can make a first PR to add the test that should work and provide value on its own. In the second PR you make the adjustments to that test.

Another way to reduce PR sizes is to make refactoring PRs. When you add a complex new feature you might need to restructure the code. This restructuring does not change the behavior of the code, but makes it more…