GitHub: Pull requests

Join the AI Workshop to learn more about AI and how it can be applied to web development. Next cohort February 1st, 2026

The AI-first Web Development BOOTCAMP cohort starts February 24th, 2026. 10 weeks of intensive training and hands-on projects.


In a previous lesson I introduced what a Pull Request (PR) is.

Starting from your repository, a person forks it, makes some changes, then creates a PR to ask you to merge those changes.

A project might have hundreds of PRs, generally the more popular a project, the more PRs, like the React project:

React Pull Requests

Once a person submits a PR, an easy process using the GitHub interface, it needs to be reviewed by the core maintainers of the project.

Depending on the scope of your PR (the number of changes, or the number of things affected by your change, or the complexity of the code touched) the maintainer might need more or less time to make sure your changes are compatible with the project.

A project might have a clear timeline of changes they want to introduce. The maintainer might like to keep things simple while you are introducing a complex architecture in a PR.

This is to say that not always a PR gets accepted fast, and also there is no guarantee that the PR will even get accepted.

In the example I posted above, there is a PR in the repo that dates back 1.5 years. And this happens in all the projects.

Lessons in this unit:

0: Introduction
1: GitHub issues
2: Social coding
3: ▶︎ Pull requests
4: Project management
5: Comparing changes
6: Webhooks and integrations
7: What happens after pushing
8: Create a GitHub account
9: Using GitHub desktop
10: Using Git in VS Code
11: A developer's introduction to GitHub
12: How to set up Git and GitHub from Zero
13: How to authenticate to GitHub using username and password
14: How to make your first Pull Request on GitHub
15: Benefits of using Git (and GitHub) as a solo dev