A pull request (PR) is how you ask permission to merge your changes into the main project. On GitHub, you click the yellow banner or go to the Pull Requests tab, choose your branch, write a description, and click Create Pull Request. Use 'Closes #X' in your description to automatically link and close related issues when the PR is merged.
What Is a Pull Request and Why Do You Need One?
A pull request is a proposal to merge changes from one branch into another. Think of it like raising your hand in a meeting and saying, 'I made some changes — can someone review them before we add them to the final version?' Pull requests are the heart of collaboration on GitHub. They let teammates review code, leave comments, suggest edits, and approve changes before anything touches the main project. Even if you are working solo, PRs create a clear record of what changed and why. When you push changes to a branch, GitHub often shows a yellow banner at the top of your repository page saying 'Compare & pull request.' That is the fastest way to start. You can also create a PR manually from the Pull Requests tab. Inside your PR description, writing 'Closes #12' will automatically close issue number 12 when the PR is merged — keeping your project tidy without extra clicks.
Prerequisites
- A free GitHub account at github.com
- A repository with at least two branches (main and one other)
- At least one commit on your non-main branch that differs from main
Step-by-step guide
Open your repository on GitHub
Open your repository on GitHub
Navigate to github.com and click on the repository where you pushed changes. If you recently pushed a new branch, look for a yellow banner near the top of the page that says 'Your branch had recent pushes — Compare & pull request.' This banner is the fastest shortcut. If you see it, click the green 'Compare & pull request' button and skip to Step 3. If the banner is not visible, continue to Step 2.
Expected result: You are on your repository's main page and can see the yellow banner or the tabs at the top.
Navigate to the Pull Requests tab
Navigate to the Pull Requests tab
Click the 'Pull requests' tab near the top of your repository page — it sits between 'Issues' and 'Actions.' On the Pull Requests page, click the green 'New pull request' button on the right side. You will see two dropdown menus: 'base' (the branch you want to merge INTO, usually main) and 'compare' (the branch that has YOUR changes). Select the correct branches. GitHub will show you a comparison of the differences. If it says 'Able to merge' with a green checkmark, you are good to go. Click 'Create pull request.'
Expected result: You see the pull request creation form with a title field and description box.
Write a clear PR title and description
Write a clear PR title and description
GitHub auto-fills the title from your last commit message. Edit it to be descriptive — for example, 'Add pricing page with monthly and annual toggle.' In the description box, explain what your changes do and why. If this PR fixes an issue, type 'Closes #X' where X is the issue number (for example, 'Closes #7'). This tells GitHub to automatically close that issue when the PR is merged. You can also add bullet points summarizing key changes. Tools like Lovable and Cursor auto-generate PR descriptions — if your AI tool created the branch, check if it already wrote a helpful summary.
Expected result: Your PR has a clear title, a description explaining the changes, and any linked issues referenced with 'Closes #X.'
Add reviewers and labels
Add reviewers and labels
On the right sidebar of the PR creation form, you will see sections for Reviewers, Assignees, Labels, and Projects. Click the gear icon next to 'Reviewers' to search for and select teammates who should review your changes. Click 'Labels' to tag the PR — common labels include 'bug,' 'enhancement,' or 'documentation.' These are optional but help teams stay organized. If you are working solo, you can skip this step.
Expected result: Reviewers and labels appear in the right sidebar of your PR.
Create the pull request
Create the pull request
Click the green 'Create pull request' button at the bottom of the form. Your PR is now open and visible to your team. GitHub will run any automated checks (like tests or build previews) and display the results at the bottom of the PR page. If everything passes, a reviewer can click 'Merge pull request' to add your changes to the main branch. If you need help managing complex PRs across multiple repositories, RapidDev can help set up automated workflows and review processes.
Expected result: Your pull request is now open with a unique number (like #15) and is visible on the Pull Requests tab.
Complete working example
1## What this PR does23- Adds a new pricing page with monthly and annual toggle4- Includes three pricing tiers: Free, Pro, and Business5- Connects Stripe checkout buttons to payment links67## Why89Users need to see pricing before signing up.10This addresses user feedback from issue #12.1112Closes #1213Closes #151415## Screenshots16171819## How to test20211. Navigate to /pricing222. Toggle between monthly and annual233. Click each "Get Started" button244. Verify Stripe checkout opens2526## Checklist2728- [x] Tested on mobile and desktop29- [x] No console errors30- [x] Linked related issuesCommon mistakes when creating a Pull Request in GitHub
Why it's a problem: Merging into the wrong base branch
How to avoid: Always check the 'base' dropdown before creating your PR. It should usually be 'main' or 'master' unless you are merging into a feature branch.
Why it's a problem: Writing vague PR titles like 'Update files'
How to avoid: Use a specific title that describes the change: 'Add user login page with email and password fields.'
Why it's a problem: Forgetting to link related issues
How to avoid: Add 'Closes #X' in the PR description so the issue closes automatically when the PR merges.
Why it's a problem: Creating a PR with no description
How to avoid: Always write at least 2-3 sentences explaining what changed and why. Future you will thank present you.
Why it's a problem: Not checking for merge conflicts before requesting review
How to avoid: Scroll to the bottom of your PR page. If GitHub shows a conflict warning, resolve it before asking for reviews.
Best practices
- Keep PRs small and focused — one feature or fix per PR makes reviews faster.
- Write a descriptive title starting with an action verb: 'Add,' 'Fix,' 'Update,' 'Remove.'
- Include screenshots or screen recordings for any visual changes.
- Link every PR to at least one issue using 'Closes #X' in the description.
- Request review from at least one teammate, even on small changes.
- Respond to review comments promptly — unresolved conversations block merging.
- Use labels to categorize PRs (bug, feature, docs) so the team can filter them.
- Delete the branch after merging to keep your repository clean — GitHub offers a button for this.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I just pushed a branch called 'feature/pricing-page' to my GitHub repository. Walk me through creating a pull request on the GitHub website, step by step with screenshots descriptions. I want to link it to issue #12.
Frequently asked questions
Can I create a pull request on a free GitHub account?
Yes. Pull requests are available on all GitHub plans, including the free tier. You can create unlimited PRs on public and private repositories.
What happens if my pull request has merge conflicts?
GitHub will show a warning at the bottom of the PR page saying the branch has conflicts. You can click 'Resolve conflicts' to fix them directly in the browser editor, or ask a teammate to help.
Can I edit a pull request after creating it?
Yes. You can edit the title, description, reviewers, and labels at any time by clicking the pencil icon or the gear icons on the PR page. You can also push more commits to the same branch — they will automatically appear in the PR.
What does 'Closes #X' do in a pull request?
When you write 'Closes #12' in your PR description and the PR is merged, GitHub automatically closes issue #12. This works with 'Closes,' 'Fixes,' and 'Resolves' followed by the issue number.
How do I know when my pull request is ready to merge?
Look for green checkmarks next to any automated checks at the bottom of the PR, and ensure all requested reviewers have approved. The green 'Merge pull request' button becomes available when all requirements are met.
Do AI app builders like Lovable or Cursor create pull requests automatically?
Lovable syncs directly to main and does not create PRs by default. Cursor and V0 can create branches that you then open as PRs on GitHub. The process for creating the PR on GitHub is the same as described in this guide.
Can RapidDev help with setting up pull request workflows?
Yes. RapidDev helps teams configure PR templates, branch protection rules, automated checks, and review workflows so your GitHub process runs smoothly from day one.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation