DEV Community

Cover image for Writing Your First Pull Request: Tips, Best Practices, and AI-Powered Tools for Success
BekahHW for OpenSauced

Posted on

Writing Your First Pull Request: Tips, Best Practices, and AI-Powered Tools for Success

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.

Jerry McGuire “Help me, help you gif”

This file—often called—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 title examples
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:

  1. 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.

  2. 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.

  3. 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 Examples for communication style
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.

gif of Nick Taylor’s 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)

bdougieyo profile image
Brian Douglas • Edited

Found my first PR.

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.

0vortex profile image
TED Vortex (Teodor Eugen Duțulescu)

this is cool

mtfoley profile image
Matthew Foley

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!
PS - I like this little tool @bdougieyo

shirenekboyd profile image
Shirene Kadkhodai Boyd

Thanks @bekahhw, this was a great article for newbies just learning and oldies getting a bit lazy or complacent.

0vortex profile image
TED Vortex (Teodor Eugen Duțulescu)

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

itsahsanmangal profile image
Ahsan Mangal 👨🏻‍💻

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.

codergirl1991 profile image
Jessica Wilkins • Edited

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.

developerdoran profile image
Jake Doran

Nice article on the basics of PR creation. A related and interesting (while perhaps a bit extreme) article on more advanced Pull Requests is:

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!