0% found this document useful (0 votes)
5 views

Sample Pull Request

Uploaded by

Evaline Yan
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views

Sample Pull Request

Uploaded by

Evaline Yan
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

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:

1. Make sure you have tested your code.


2. Make sure you're on a new branch, usually prefixed with your username, eg.
jdoe/add-unit-tests-array Ths branch name doesn't have to be very descriptive.
3. Rebase/merge your code with main (and fix any merge conflicts locally to make
your life easier). git pull --rebase
4. Interactively rebase your commits if it makes sense to clean them up before
pushing. git rebase -i
5. Push your code to the repo to create a PR

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

Alternatively you can also utilize an image hosting service


like a shared Google Drive folder but this isn't the best
when using your personal account since the images rely on you
to always have those files up in the future.

Testing
Always provide a reproducible list of how you tested your changes. For example:

1. Ran automated tests locally:

running local dev server using command


navigating to localhost:3000/tests

2. Manually went through the steps to reproduce the problem in local dev server:

List of steps to reproduce the problem, which is now solved in this PR

You might also like