DEV Community

Cover image for How to Collaborate on Pull Requests for Beginners
Christine Belzie for OpenSauced

Posted on

How to Collaborate on Pull Requests for Beginners

A Reflection

As cliche as it sounds, two hands are better than one. Whether it’s giving code reviews to another person’s pull request or adding your points in the comment section of an issue they raised, Whether it’s giving code reviews to another person’s pull request or adding your points in the comment section of an issue they raised, you'll find that collaboration is a key skill in open source development. One of the most common ways you would do this is by working with others on pull requests. Now don’t fret. In this blog post, I will share 5 tips on how to collaborate with others on a pull request.

Tip #1: Pick the Right Repository

When collaborating on a pull request for an open-source project, especially one that has multiple repositories, you want to make sure that you have the right repository. For example, I decided to fork the repository for OpenSauced’s intro course so I could translate their course’s content into French with Geoffrey, a contributor from Togo, Africa. Think of this part as going through Google Drive or OneDrive and picking the right file you want to share with your coworkers or colleagues at school. From there, you want to clone the repository. Check out the Setup section of our Contributing Guide to get an idea of how to do this process. Now choosing the right repository is only one step to collaborating on pull requests. Let’s look at another.

Tip #2: Pick a collaboration method that suits you

Now that you’ve picked and forked the repository you want to work on, decide with your partner what collaboration method best suits your needs. The most common is pair programming, which entails one person writing the code and the other reviewing each line and navigating the codebase. Now, there are other styles of paired programming that might strike you and your partner’s interest:

  • The Unstructured Pair Style: This style entails developers writing code and navigating the codebase at the same time. It’s highly recommended for sessions or projects that do not need to be worked on for a long period of time.
  • Distributed Pairing: This style is when developers or tech professionals work asynchronously on a codebase. This approach is great for teams who need the flexibility to work on tasks at different times.
  • Mob programming: This method is similar to pair programming in that one person writes the code. What makes mob programming different is that a group of developers or tech-related professionals navigate the codebase. Since Geoffrey and I have a large gap in our time zones, we chose to do an asynchronous approach to disturbed pairing. To make it easier for us to collaborate, I sent Geoffrey an invitation email via GitHub. If you want to learn more about this process, check out the article, Inviting collaborators to a personal repository. Great, you’ve picked your collaboration method! 😀 Now, let’s move on to the next tip.

Tip #3: Keep an extra PR

I know this sounds strange, but hear me out. Git and the internet can get finicky with workflows sometimes. Case in point, I noticed that there were a few merge conflicts in my branch. So, I tried the following Git commands to solve this issue:

  • git revert: This will undo any changes made in a previous commit. I decided to use the command to get rid of the merge conflicts. Unfortunately, it did not work as most of the commits I wanted were not in the order I wanted.
  • git-force push: This command overrides the commit history on the remote with your local one. In other words, all of your work can be gone. Sadly, this outcome occurred when I tried using this command to remove the merge conflicts in my translation PR's branch.
  • git-cherry-pick: This command picks commits from one branch and puts it on another branch. Now this is where my second tip comes into play. I remembered that Geoffrey had most of the commits on his fork, so I went to his branch, used the cherry-pick command, and our commit history was restored.

If you want to learn more about these and other Git commands to use when making open source contributions, check out this simple Git cheat sheet at freeCodeCamp's website. Now that you understand the power of an extra PR, let’s move on to another tip!

Tip #4 Ask for help

I know tech spaces often tell you to try and figure things out by yourself, but like most things in life, there are programming languages or other tech-related topics that you don’t know how to do. So, it’s okay to ask for assistance if the other methods you tried haven’t helped solve your problem. For instance, one of the maintainers at OpenSauced pointed out that the sidebar would not direct her to the translated French version of the course when clicking on the French flag. At first, I tried creating a different page, but that still did not work. So, I asked Geoffrey for help. He pointed out that the issue was happening because the file paths that linked the chapters to each section were written incorrectly, and guided me on how to correct them. After that, the pages worked! 😊 Now before I let you go, there’s just one more tip I have for you.

Tip 5: Show Appreciation

As obvious as this tip sounds, showing your partners appreciation for their work is a great way to collaborate with others on your pull request. It shows them you’re grateful for their help. Now you can do what I did and mention them in a blog post about your experience, but if you’re looking for other ways, here are some suggestions:

  • Tag their usernames when describing the contribution in your PR’s form: To do this, you do the following: @yourpartner’s GitHub name
  • Add their names to your commits: Adding their names to your commits would not only show your collaboration skills(which can be very useful for job interviews), but it’ll also add a GitHub badge to their profile. To learn how to do this, check out the article, Creating a commit with multiple authors.

There you have it folks. Five tips on how to collaborate with others on your pull requests. Doing this in your open source journey would greatly prepare you for your tech role. Now if you’re looking for a project and people to work with, check out our pizza verse repository to submit a pizza recipe, fact about your hometown’s pizza, or trivia about pizza. While you’re there, join our Discord community to learn about other projects to contribute to. We look forward to working with you! 😊

Top comments (5)

Collapse
 
scastiel profile image
Sebastien Castiel

Nice tips! Showing appreciation is very important, as well as highlighting the amazing work by your peers during the code review!

I published a post with some tips for better pull requests and code review that bring some additional insights 😉

Collapse
 
irina_kats profile image
Irina Kats

The post is good but kind of very basic. I found more advanced tips in the comment below. Maybe they might benefit others too.

Collapse
 
cbid2 profile image
Christine Belzie

Hi, @irina_kats. This post was meant for people who are very new to open source, so of course it's going to be “very basic”.

Collapse
 
irina_kats profile image
Irina Kats

No problem. This post does makes good points about collaboration!

Collapse
 
chinwenma profile image
Chinwenma Okorie

Great!