With Hacktober currently running, many developers want to contribute to open source. This seems scary for some of us (at least it was for me) and leaves some with many unanswered questions: where to start, how to contribute, how to work on problems, and more.
One of the common questions that comes up is how to create a pull request (PR, sometimes also called Merge Request, short MR). Some repositories provide an example with a detailed explanation of how to write a PR when contributing to their project, and some do not.
What Is A Pull Request You Ask?
When you make changes to code, whether in your organization or as a contribution to open source, you must write a PR to have your code reviewed before it is merged into the main branch (often called master).
The purpose of a PR is to give your reviewers context about your code before it is merged into a larger part of the project or application as a whole. This is an opportunity to explain why you made certain decisions regarding your code, what the benefits of this approach are as opposed to another, and more.
Snippet of a PR
Here are an example that can really help you write an good PR by showing screenshots or videos of what the code does on the user interface.
Link to resources and permalinks to code that you reference outside of the PR so that you can not only share how a code works, but also link to it.
If a little more context is needed to explain the concept of the code you used in detail, you can link to the e.g. documentation with a more detailed description of the topic of the concept which is being used. This is a nice experience for your code reviewers if you have more to say, which can be supported by letting them decide if they want to follow the link or not.
Last but not least, it is important that we ourselves review our code again before asking others to review it. Ask yourself if my final changes are acceptable, what questions might I have. Sometimes we are just happy to have finally finished the code and want to finish the PR as soon as possible.
This prevents the reviewer from telling me to change something that I would have seen myself if I had reviewed it before sending the PR. It saves a little extra time between updating the code and merging the code.
Taking that extra step before asking others to review makes communication between the reviewer and yourself more efficient.
Example of an PR
Look at this example of a pull request for a section within a form.
Markdown of the PR
## Description
This PR adds one new component for displaying a section **experience** in the form.
## Related Issue
Closes #11
<!-- Put an `✓` for the applicable box: -->
| | Type |
| --- | -------------------------- |
| | :bug: Bug fix |
| ✓ | :sparkles: New feature |
| | :hammer: Refactoring |
| | :100: Add tests |
| | :link: Update dependencies |
| | :scroll: Docs |
## Acceptance Criteria
- [x] The user sees a form for the section **experience**
- [x] The user can add an experience
- [x] The user can click on `save button` to save their experience in localStorage
## Updates
### Fill out the form
The user now sees a form where they can add their experience and save it.
## Testing Steps / QA Criteria
* Fill out the form with a new experience.
* Click `save` to save your data to `localStorage`.
* Make sure the `save` button is clickable and responses.
Still looking for (beginner friendly) contributions to Hacktoberfest?
Check out my organization YurisCodingClub on GitHub. I will be happy to meet you there .
Top comments (2)
Good guide it can be challenging for beginners to understand all of these concepts and acronyms you explained them well.
Thanks Andrew.