Hi @Northout-Salman. You can think of a pull request as your desire or intention to incorporate new changes into a project. If you're a collaborator on a project and you have some changes to make to that project, you can make those changes in the form of commits and then open a pull request to let others know about changes you want to make. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before the changes are merged into the project.
Here is a great article explaining more about pull requests and how you can use them in a project, or repository, on GitHub.
In addition to the overview described by @a-a-ron, here is a recent Pull Request to the Atom editor by one of the project's maintainers:
You can see from the title of the PR what the change was intended to do. The initial body goes into more detail. Then there was some discussion and finally the PR was merged after some follow-on actions were decided upon.
This post was moved to a different board that fits your topic of discussion a bit better. This means you’ll get better engagement on your post, and it keeps our Community organized so users can more easily find information.
As you’ll notice, your Topic is now in the How to use Git and GitHub board. No action is needed on your part; you can continue the conversation as normal here.
Think of a pull request like an article or blog post you'd like to publish that's written on a very specific topic, like general relativity, thermodynamics, replacing a car battery, etc.
In general, it's best to have someone else proof-read what you've written before it's published to make sure everything you've written is accurate and will make sense to the reader.
You may get some typo corrections, recommendations to re-arrange sentences, or even a correction on information that could be misleading.
This is generally how a pull request works. It's a request to publish code and have those code changes reviewed by someone else to make sure the changes will do what they're intended to do, won't cause any unexpected problems, and will be relatively easy for someone else to understand.
The core purpose is not to offer a critique or evaluation, per se, but rather to foster collaboration between developers and ensure the quality and function of the code that's being published.
I'm developing a step-by-step guide to GitHub contributing at https://stackoverflow.com/questions/54390541/how-to-contribute-to-a-github-open-software-repository/ . This will be the kind of tutorial I have been looking for for weeks and have not found.