Optimize your PRs for revertability
Imagine you've grabbed a GitHub issue called
Add a last name field to the signup form from your issue backlog. While you're adding code to display a last name field, you realize that there's another React component named
Heder instead of
Header. You add the last name field, and you fix the spelling of
Header. You submit a PR. Your teammates love the changes, and you merge them into master.
Thirty minutes later, a new error pops up in your error tracking service. There was an error in your code, and new users can't sign up! Your team decides the best move is to revert the PR. You revert the PR. But wait! You just changed
Header back to
When working on a new feature area, you will undoubtedly find some areas in your existing codebase that can be improved. If you feel the need to improve some code you come across that's unrelated to the feature you're working on, make the changes in a separate PR.
Thinking in terms of revertability allows you to establish clear boundaries between changes and will result in PRs that are easier for your teammates to review.