Pull Requests

In the previous chapters, we learned a common development workflow: create a branch from main, make changes, commit them, and push the branch to GitHub. The next step is getting that work back into main.

In team projects, developers often do not immediately merge locally with:

git merge feature/login

and then push directly to main. Instead, they usually open a Pull Request, commonly shortened to PR.

A Pull Request is basically saying:

I have made some changes on my branch. I would like to merge them into another branch, but let's review them first.

Suppose you are building a login feature:

main → feature/login

You finish the work and push the branch:

git add .
git commit -m "Add login feature"
git push -u origin feature/login

Now feature/login exists on GitHub, and you can open a Pull Request to merge it into main.

Why Not Work Directly on main?

For a tiny personal project, working directly on main may be acceptable. In a team, however, allowing everyone to push directly to main makes it harder to review changes before they become part of the main codebase.

A Pull Request adds a review step:

Create branch → Edit code → Commit → Push branch → Open Pull Request → Code review → Automated checks → Merge

This gives other developers a chance to understand and check the work before it reaches main.

Creating a Pull Request

Suppose you have already pushed:

feature/login

to GitHub.

GitHub will often notice the recently pushed branch and offer a shortcut for creating a Pull Request. You can also go to the repository's Pull requests page and create one manually.

The most important part is choosing the correct branches:

base:    main
compare: feature/login

The base branch is the branch receiving the changes. The compare branch contains the work you want to merge.

You can picture it as:

feature/login → Pull Request → main

What Should You Write in a PR?

A Pull Request normally has a title and a description.

The title should briefly explain the change:

Add login page
Fix payment timeout
Improve search results

The description can provide a little more context, such as why the change is needed, what was modified, and what you tested.

For example:

This PR adds the login page and basic form validation.

Changes:
- Add email and password fields
- Add required-field validation
- Show an error message when the form is incomplete

The goal is not to write a long report. The goal is to help reviewers understand the change quickly.

Reviewing the Diff

GitHub shows the differences between the two branches inside the Pull Request. You can see which files changed, which lines were added, and which lines were removed.

This is the same basic idea as the VS Code diff used earlier, but now the comparison is available online.

The Files changed section is especially useful:

feature/login → compare with main → Files changed

Before asking someone else to review the PR, it is a good idea to review this page yourself. You may catch temporary debug code, unrelated files, or accidental changes.

What Is Code Review?

Code review means another developer examines your changes and leaves feedback.

For example, a reviewer may see:

if (password.length < 4) {

and ask:

Should the minimum password length be 8 instead?

Or they may suggest simplifying duplicated logic.

Code review does not necessarily mean the code is wrong. It is a collaboration process that helps catch bugs, improve consistency, and make sure more than one person understands important changes.

Can You Keep Updating a PR?

Yes.

Suppose a reviewer asks you to fix something. You do not need to close the Pull Request and create a new one.

Continue working on the same branch:

git switch feature/login

Make the change, then:

git add .
git commit -m "Fix login validation"
git push

Because the new commit was pushed to the same branch, the existing Pull Request updates automatically.

Conceptually:

Pull Request
     ↑
     |
feature/login
     ↑
     |
new commits

Merging the Pull Request

Once the review is complete and automated checks have passed, the Pull Request can be merged into main.

GitHub normally provides a button such as:

Merge pull request

After the merge:

feature/login → main

the login feature becomes part of the main branch.

Your local main may still be outdated, so return to your local repository and run:

git switch main
git pull

to get the newly merged changes.

Deleting the Finished Branch

After the Pull Request is merged, the feature branch usually has no further purpose.

GitHub often offers a:

Delete branch

button.

You can also remove the local branch:

git branch -d feature/login

Deleting the branch does not remove the code that has already been merged into main.

A Complete PR Workflow

The full workflow looks like:

git switch main → git pull → git switch -c feature/login → Edit code → git add . → git commit → git push → Open Pull Request → Review the diff → Code review → Make updates and push again → Merge → Delete the branch

This is one of the most common basic collaboration workflows on GitHub.