Throughout my career as a software engineer, I have raised many pull requests. I have raised good ones as well as bad ones. Raising a good pull request is as important as being able to code. Raising a bad pull requests wastes everyone’s time and distract team from what is important, delivering quality code. I made so many mistakes and learned a lot of lessons. I decided to write a blog post to distill some of the wisdom on raising a good pull requests. I hope this helps you.

(1) Getting your branch ready before raising PR

• Run lint and unit tests locally to make sure they pass.
• Make sure it passes the branch build.
• Install spell checker on your IDE and eliminate as many spelling mistakes as possible.
• Make sure to perform squash commits to make the history clean (e.g. three consecutive typo fix commits should be squashed).
• Make sure PR is small and easy to review without any unrelated changes.

(2) Adding PR title

• The title of PRs should be descriptive and free of references such as card number.
• It should be free of acronyms unless you are confident everyone knows what they mean.
• Try to start with a verb and read somewhat like a sentence.

(3) Adding PR content

• Each platform has a way of making a template. It is a good idea to have template so that all the PR looks similar.

(4) Adding Reviewers

• As a rule of thumb, add people(at least 2 reviewers) who know the context (e.g. team member or people who were involved in early design discussions or kick offs).
• If you are not sure who to include, ask in the development Slack channel.

Checklist

This is a quick check list to make your PR ready for review. You can minimise unnecessary update if you go through the checklist before you raise a pull request..

1. Make sure it passes the build step.
2. Make sure you have spell checker on your IDE and have no spelling mistakes.
3. Make sure your PR is small and is dealing with one thing, not multiple unrelated changes.
4. Complete the design discussions with others to minimise the rewrite.
5. Have unit tests to verify the change.
6. Make sure to have acceptance test if unit tests do not cover the functionality.
7. Test it locally according to the acceptance criteria.