How to Create a Pull Request on GitHub
A pull request (PR) proposes changes from one branch to another so teammates can review them before they are merged. This guide walks through creating a branch, pushing your commits, opening a PR, and responding to review feedback.
Practice Git workflows →1. Create a branch for your change
Start from the project's agreed base branch, usually main. Update it if needed, then create a short-lived branch with a name that describes the work:
git switch main
git pull --ff-only origin main
git switch -c add-profile-settingsUse the base branch your team expects; it may be a release branch instead of main. Make your changes on the new branch and commit them with clear messages.
2. Review and push your commits
Before opening the PR, check which files changed and whether your commits are ready for review:
git status
git diff
git log --oneline -5Push the branch to GitHub. The -u option sets the upstream so later pushes can use git push:
git push -u origin add-profile-settingsReplace origin or the branch name if your repository uses different names. Confirm you have pushed the intended commits before sharing the branch.
3. Open a pull request on GitHub
- Open the repository on GitHub. If GitHub shows a prompt to compare your recently pushed branch, select Compare & pull request. Otherwise, open the Pull requests tab and choose New pull request.
- Choose the base branch that should receive the change and the compare branch containing your commits. Check the comparison to ensure it shows only the intended changes.
- Select Create pull request. If the work is still in progress, choose the draft option when available.
4. Write a useful title and description
A good PR makes it easy to understand why the change exists, what changed, and how it was checked. Keep the title specific and summarize the work in the description. For example:
Add profile settings page
- What changed: Added editable display name and avatar fields.
- Why: Users can update their profile without contacting support.
- Testing: Verified form validation and successful save locally.
Link related issues or tickets, call out any risks, and include screenshots for visible UI changes when useful. Follow the repository's PR template and avoid claiming tests passed if you did not run them.
5. Request review and address feedback
Add the appropriate reviewers or teams, then monitor comments and automated checks. If a reviewer requests changes, make the updates on the same branch and push them:
git add path/to/changed-file
git commit -m "Address profile settings feedback"
git pushGitHub updates the existing PR when you push to its compare branch. Reply to review comments or resolve them according to your team's process. If the base branch changed, follow the project's guidance for updating your branch.
6. Merge the pull request
Merge only when required reviews and status checks are complete and the change is ready. Use the merge method selected by the project, such as merge commit, squash, or rebase. After merging, GitHub may offer to delete the source branch; delete it only if it is no longer needed. Update your local base branch afterward with git switch main and git pull --ff-only origin main.
Pull request FAQ
Is a pull request the same as a merge?
No. A pull request is a proposal and review space for changes. Merging is a later action that integrates those changes into the target branch.
Can I update a pull request after creating it?
Yes. Commit and push additional changes to the same source branch; they appear in the existing PR. You can also edit its title and description on GitHub.