I don’t remember writing my first Pull Request (PR), and to be honest, I actually looked to see if I could find it for this post, but I know that I was really nervous because I wasn’t sure if I was doing it “right.” I think I actually spent more time worrying about it than I did actually writing the thing. The good news is that there isn’t really a right way to write a PR, but there are some best practices that can guide your writing and help the maintainer to be able to understand the changes.
Review the Contribution Guidelines
Maintainers want to help you write your PR; that’s why they often outline contributing directions in their repositories.
This file—often called CONTRIBUTING.md—gives guidelines for submitting your PR, including information like whether or not you need to write tests, the communication process, coding style, and how to submit your pull request. Check out OpenSauced’s Contributing Guide, as an example.
Tips for Your First PR
Although every repository may have unique guidelines, there are general guidelines for all PRs. Here are some tips to keep in mind:
Create a Clear Title
The title should give an indication of the issue, the changes made, and the type of PR–is this a bug fix, content or documentation change, new feature, or something else?
OpenSauced’s CONTRIBUTING guidelines for titles
Give a Detailed Description
PRs often include a summary of the changes, as well as any relevant context or background information that might be helpful in understanding the proposed changes.
Provide context
A well-written description will help the maintainer understand the purpose of the PR, the changes you’ve made, and why the changes were made. Here are some of the reasons the description is key to the success of the PR:
Facilitates collaboration. More details allow team members to share their feedback, identify potential issues, and ask questions. With open and transparent communication, a sense of community and trust among team members develops, leading to better collaboration.
Saves time. With a detailed description, the reviewer is more likely to quickly understand the changes made and avoid spending unnecessary time deciphering code. As a result, the developer will receive quicker feedback and avoid unnecessary rework.
Helps with future reference. A well-documented PR provides a historical record of the changes made. This helps future team members to understand the evolution of the code and the decisions made along the way. It also helps with future maintenance and debugging.
OpenSauced’s CONTRIBUTING guidelines for communication style
Link the issue
If the PR is related to an issue, you can link that issue and automatically close the issue when the PR is merged. One way to do this is to use this syntax: closes #issue-number for example, closes #11.
Acknowledge Requirements
If there are requirements for new code to be merged in, like writing tests or documentation, you should also include that information in the PR. Other steps might include running current tests before submitting, agreeing to the Code of Conduct, and checking to make sure there’s not an open issue or another PR addressing the same problem you’ve fixed.
Add a Gif!
If you want to know why, check out my last post, How to Create a Good Pull Request Template (and Why You Should Add Gifs)
Bonus Level: Power Up Your PRs with AI
If you want to take your PRs to the next level, sign up for GitHub’s Copilot for Pull Requests waitlist! Copilot for PRs can give a summary of the changes, a detailed list with code references, or even create a poem 🤯
Community Shoutout
For a great example from one of our community members, @nickytonline, check out this PR.
If you’re looking for an open source project to submit your first PR to, find a project that’s well documented, aligns with your interests and skills, and is accepting PRs from new contributors. Check out OpenSauced’s Hot Repositories or Insights to find popular repositories and explore based on your favorite topics. And if you want to see your PR mentioned by OpenSauced, be sure to add it to your highlights!
Top comments (8)
Found my first PR. firstpr.me/#bdougie
I had no idea how to send update to the PR, so I closed it and then opened a new PR. Erik was so patient with me.
github.com/TheOdinProject/theodinp...
this is cool firstpr.me/#0-vortex
Turns out my first PR was a job application 10 years ago last month. Ultimately didn’t pan out and then I was pretty quiet on GH until a lot later!
firstpr.me/#mtfoley
PS - I like this little tool @bdougieyo
Thanks @bekahhw, this was a great article for newbies just learning and oldies getting a bit lazy or complacent.
we can make the ai pull requests today, however, would work only for our repos atm since it’s building on top of our semantic contribution standards
the article provides a comprehensive guide to creating a successful pull request, from finding the right project to using AI-powered tools to improve your code. Whether you're a seasoned developer or just starting out, this article is a valuable resource for anyone who wants to contribute to the open source community.
Another great article @bekahhw !
I especially love the advice on doing a self review of the PR. I always look things over just to make sure I am not committing something by accident.
Sometimes I will leave comments on the PR too before an official review.
Nice article on the basics of PR creation. A related and interesting (while perhaps a bit extreme) article on more advanced Pull Requests is:
hugooodias.medium.com/the-anatomy-...
Yours did a great job of explaining how to present a PR the linked article goes more into the contents of a PR. Although it's probably more aimed at commercial settings rather than open source!