Sample Pull Request
Sample Pull Request
Code Review
Things to look for:
Accidental changes which make a whole file as changed. (\n -> \r\n, tabs ->
spaces, etc)
Accidentally committing a file they shouldn't. (e.g. yarn_error.log)
Inconsistent with the style of the rest of the file (e.g. using the wrong
number of spaces)
Variable names are good.
Comments exist if appropriate.
PR Process
This process varies somewhat depending on the repo standards and setup. Generally, it
will look something like this... Before:
After:
1. Someone reviews your code (may have to tag them on Github if it takes a while)
2. You respond to their comments, and make any necessary changes locally, then
push a new commit to the PR with the changes
3. When your PR is approved, you use the Github UI to merge it into main
PR Title
This won't be in the body of your PR, but your PR itself should follow the conventions
of the repo you're contributing to and be descriptive but concise. For example, some
repos follow a convention using feat: or fix: before the rest of the title to
identify the type of PR. This isn't a global rule, however, it's important your PRs
are descriptive enough.
Example of a decent PR title: feat: Adds missing unit tests for custom array
utils
Example of a bad PR title: Add unit tests
PR Description Philosophy
Having a good PR description can get skipped over often especially when developers are
just trying to merge their code to main. But good documentation helps both prevent bad
code from getting commited and greatly helps out future developers who are scratching
their heads trying to investigate old PRs for what/when/why a change was made. Having
good commit messages helps in this respect; PRs often contain collections of such
commits, and should be understandable in themselves.
As for the actual PR description itself, there are things you can do to make it a
better PR. This is definitely not a comprehensive list and people will prefer
different things, so take this as just one example.
Issue
This PR fixes Issue # : Name of issue . The Issue # should be automatically linked to
by Github.
Summary
This is a summary of the changes in the PR. This should be no longer than a few
sentences and detail the important changes in the PR.
Details
This is a section where you can go into more detail about your PR. For example,
implementation details about the files you changed.
Detail #1
Detail #2
.. and so on
Screenshots
Provide screenshots and/or screencaptures if you are making something that
involves a UI change. You can also put this in a table to show before/after.
Before After
Image and
Image and description
description
Image and
Image and description
description
Testing
Always provide a reproducible list of how you tested your changes. For example:
2. Manually went through the steps to reproduce the problem in local dev server: