# Elliotte Rusty Harold

Published articles for Elliotte Rusty Harold.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## In Praise of Small Pull Requests

DevFeed: [In Praise of Small Pull Requests](<https://devfeed.tech/articles/in-praise-of-small-pull-requests-23858.md>)

Original publisher: [Read original article](<http://testing.googleblog.com/2024/07/in-praise-of-small-pull-requests.html>)

Author: Google Testing Bloggers (noreply@blogger.com)

Published: 2024-07-16T13:00:00Z

Content type: article

Language: en

Sources: [Google Testing Blog](<https://devfeed.tech/sources/google-testing-blog.md>)

Topics: [pull-requests](<https://devfeed.tech/topics/pull-requests.md>), [Code review](<https://devfeed.tech/topics/code-review.md>), [engineering-culture](<https://devfeed.tech/topics/engineering-culture.md>)

Tags: [code-health](<https://devfeed.tech/tags/code-health.md>), [code-review](<https://devfeed.tech/tags/code-review.md>), [elliotte-rusty-harold](<https://devfeed.tech/tags/elliotte-rusty-harold.md>), [merge](<https://devfeed.tech/tags/merge.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>), [review](<https://devfeed.tech/tags/review.md>), [tott](<https://devfeed.tech/tags/tott.md>), [version-control](<https://devfeed.tech/tags/version-control.md>)

### AI overview

This Google Testing on the Toilet Code Health post explains why pull requests should be small and focused on one self-contained change. It says smaller pull requests are easier and faster to review, make mistakes easier to detect, simplify debugging and rollback, reduce merge conflicts, improve pull request descriptions and revision history, and can increase code coverage.

### Source excerpt

This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Testing on the Toilet episode. You can download a printer-friendly version to display in your office. By Elliotte Rusty Harold Note: A "pull request" refers to one self-contained change that has been submitted to version control or which is undergoing code review. At Google, this is referred to as a"CL", which is short for "changelist". Prefer small, focused pull requests that do exactly one thing each. Why? Several reasons: Small pull requests are easier to review. A mistake in a focused pull request is more obvious. In a 40 file pull request that does several things, would you notice that one if statement had reversed the logic it should have and was using true instead of false? By contrast, if that if block and its test were the only things that changed in a pull request, you'd be a lot more likely to catch the error. Small pull requests can be reviewed quickly. A reviewer can often respond quickly by slipping small reviews in between other tasks. Larger pull requests are a big task by themselves, often waiting until the reviewer has a significant chunk of time. If something does go wrong and your continuous build breaks on a small pull request, the small size makes it much easier to figure out exactly where the mistake is. They are also easier to rollback if something goes wrong. By virtue of their size, small pull requests are less likely to conflict with other developers' work. Merge conflicts are less frequent and easier to resolve. If you've made a critical error, it saves a lot of work when the reviewer can point this out after you've only gone a little way down the wrong path. Better to find out after an hour than after several weeks. Pull request descriptions are more accurate when pull requests are focused on one task. The revision history becomes easier to read. Small pull requests can lead to increased code coverage becau