Creating Pull Requests and Requesting Reviews

A Pull Request (PR) is a way to ask your team members to “please merge these changes from my branch into main.” Using PRs ensures that code changes go through a review before being reflected in production, preventing bugs from slipping through.

In team development, PRs are at the center of the development cycle. This article walks through the entire process from creating a PR to merging it.

Target audience: Those who have learned branch and push operations (git branch / git push)

Estimated learning time: 15 min reading + 20 min hands-on

Prerequisites: Complete Branches and Merging before proceeding

What Is a Pull Request?

A PR is a mechanism for code review. Beyond simply “merging changes,” it provides the following value:

PR Role	Description
Code review	Team members can check changes and point out bugs or improvements
Change history	Why a change was made and what discussions happened are recorded on GitHub
Quality gate	Changes cannot be merged into main until tests pass and reviews are approved
Knowledge sharing	Reviews help the entire team understand the code

Why Use PRs Even When Working Alone

Building a habit of using PRs even solo provides these benefits:

The intent of changes becomes clear later (“why was this changed” remains in the log)
Self-review is possible in the Files changed tab (easier to spot bugs)
GitHub Actions can run tests automatically

Creating a PR

Prerequisite: Push Your Working Branch

To create a PR, first push your working branch to GitHub.

git push origin feature/add-search-function

After pushing, a yellow banner with a “Compare & pull request” button will appear on the repository page.

Creating from “Compare & pull request”

Click the “Compare & pull request” button to open the PR creation page.

If time has passed since the branch was pushed, you can also create one from the “Pull requests” tab → “New pull request.”

How to Fill in PR Fields

Field	Description	Example
Title	What was done in one line	`feat: Add user search functionality`
Description	Changes, reason, and how to test	Fill in using a template
Reviewers	Person to request review from	Assign a team member
Labels	Tags indicating the type of PR	`bug` / `enhancement` / `documentation`
Assignees	Person responsible for the PR (usually yourself)	Set yourself
Linked Issues	Link related Issues	`Closes #42` (auto-closes on merge)

Description Template

## Changes
- Added user search functionality
- Added a component for displaying search results

## Reason for Changes
To respond to the user request in Issue #42.

## How to Test
1. Start the app
2. Type a name in the search bar in the header
3. Confirm that search results are displayed

## Related Issue
Closes #42

Writing Closes #number automatically closes the Issue when the PR is merged.

Draft Pull Request

Use a Draft PR when “review isn’t needed yet, but I want early feedback.”

Click the ”▼” on the right side of the “Create pull request” button → select “Create draft pull request.”

Draft PRs:

Display a “Draft” label
Have the merge button disabled
Can be converted to a regular PR using the “Ready for review” button when work is complete

Useful when you want to confirm the direction of implementation early or receive review comments while work is in progress.

Understanding the PR Page

The PR page has 4 tabs.

Tab	Content
Conversation	List of comments and discussions. The merge button is also here
Commits	List of commits on this branch
Checks	Results from automated tests like GitHub Actions
Files changed	Diff of changed files

Checking Diffs in “Files changed”

The “Files changed” tab shows the diff between before (red) and after (green).

Click the ”+” button on a line to add a comment to that line
Multiple lines can also be selected for a comment

Always perform self-review in the “Files changed” tab.

Responding to Review Comments

Revise Code After Receiving a Comment

When a reviewer leaves a comment, revise the code locally and commit.

# Revise the code
git add .
git commit -m "fix: Address review feedback - add validation"
git push origin feature/add-search-function

Pushing automatically adds a new commit to the PR. The reviewer is notified of the change.

Close Resolved Comments

Click the “Resolve conversation” button on comments that have been addressed. Resolved comments are collapsed, making unresolved items stand out.

Request Re-review

When revisions are complete, ask the reviewer for another look. Click the refresh icon (↺) on the right side of the “Reviewers” section to “Re-request review.”

How to Merge

Once the reviewer gives an “Approve,” the PR can be merged. GitHub offers 3 merge methods.

Merge Method	Feature	Recommendation for Beginners
Merge commit	All commits are preserved, a merge commit is created	Moderate
Squash and merge	Squashes branch commits into one	Recommended
Rebase and merge	Creates a linear history without merge commits	For advanced users

“Squash and merge” is most recommended for beginner teams. Work-in-progress commits like “WIP” and “fix” don’t remain in the main history, and the intent of changes is consolidated into a single commit.

Deleting the Branch After Merging

A “Delete branch” button appears after merging. It is recommended to delete merged branches. Having too many unnecessary branches makes management cumbersome.

PR Creation Checklist

Check the following before submitting a PR:

- [ ] The title represents "what was done" in one line
- [ ] The description includes changes, reason, and how to test
- [ ] Self-review was done in "Files changed"
- [ ] A reviewer was assigned
- [ ] Related Issue is linked with Closes #number
- [ ] No conflicts exist
- [ ] (If CI is set up) Tests are passing

FAQ

Q. Does pushing commits to a PR automatically update it?

Yes. Just push to the same branch and the PR is automatically updated. When a new commit is added, the reviewer is notified.

Q. How do I decide between Draft PR and a regular PR?

Use a regular PR when implementation is complete and “I want a review now.” Use a Draft PR when “I’m still working but want to confirm the direction” or “I want to align on specs.” A Draft PR doesn’t pressure reviewers to merge.

Q. What should I do if there’s no reviewer (working alone)?

PRs still have value when working alone. Self-review in the “Files changed” tab, record the intent of changes in the description, and then merge. If GitHub Actions automates testing, you can confirm tests pass before merging.

Q. Should PR descriptions be written in English?

Follow your team’s common language. Japanese teams can use Japanese without issue. In teams mixing English and Japanese speakers, English often becomes the standard.