A pull request (PR) is a way of asking permission to merge your changes into the main branch. Think of it like sending a marked-up draft to your editor — you're saying "here's what I changed, please review it before it goes live." The reviewer can approve, request changes, or comment. Once approved, you click a button to merge and your changes become part of the main project.
Pull Requests Explained — The Draft Review Analogy
Imagine you're writing a report with a teammate. Instead of editing the master copy directly, you write your section on a separate page and hand it to your teammate with a note: "Here are my additions — take a look and let me know if this is good to include." Your teammate reads it, suggests a tweak, and once you both agree, the new section gets added to the master copy. That's exactly what a pull request does on GitHub. You make changes on a separate branch, then open a pull request to propose merging those changes into the main branch. The pull request shows exactly what was added, removed, or changed — line by line. Other team members can review the changes, leave comments, and approve or request edits. This review process is what makes teams confident that nothing breaks when new changes go live. AI tools use pull requests too: when V0 generates code for your project, it creates a branch and opens a pull request automatically, so you can review the AI's changes before they become part of your main codebase. Lovable can also work with pull requests when branch switching is enabled. Understanding PRs is fundamental to collaborating on any GitHub project.
Prerequisites
- A GitHub account
- A repository with at least two branches (main and a feature branch)
- Basic understanding of what branches are (see our branches tutorial)
Step-by-step guide
Navigate to the Pull Requests tab
Navigate to the Pull Requests tab
Open your repository on github.com and look at the row of tabs near the top: Code, Issues, Pull Requests, Actions, and more. Click the "Pull requests" tab. If this is a new repository, you'll see a message saying there are no open pull requests yet. This tab is where all pull requests live — open ones, closed ones, and merged ones. You can filter by status using the buttons at the top. If your repository already has pull requests (perhaps from a V0 integration), you'll see them listed here.
Expected result: You see the Pull Requests tab with a list (possibly empty) of pull requests.
Open a new pull request from your feature branch
Open a new pull request from your feature branch
Click the green "New pull request" button. GitHub will show you a comparison page with two dropdown menus at the top. The left dropdown ("base") is where you want to merge into — this should be "main." The right dropdown ("compare") is the branch with your changes — select your feature branch (like "add-about-page"). GitHub will automatically show you a diff — a side-by-side comparison of what changed. Lines highlighted in green are additions, and lines highlighted in red are removals. Review this to make sure the changes are what you intended.
Expected result: You see a comparison showing the differences between main and your feature branch.
Write a clear title and description for your pull request
Write a clear title and description for your pull request
Click the green "Create pull request" button to proceed to the PR form. In the title field, write a clear, short summary of what the PR does — for example, "Add About page with team bios." In the larger description box below, write a few sentences explaining why you made these changes, what the reviewer should pay attention to, and any context they need. If you're working with a team, this description helps reviewers understand your intent without having to read every line of code. You can use Markdown in the description — bullet lists, headings, and even task checklists all work.
Expected result: Your pull request form has a descriptive title and a helpful description.
Create the pull request and review the changes
Create the pull request and review the changes
Click the green "Create pull request" button at the bottom of the form. Your PR is now open and visible in the Pull Requests tab. The PR page has several tabs: Conversation (discussion and comments), Commits (list of individual changes), and Files changed (the full diff). Click "Files changed" to see every modification. You can click the + icon next to any line to leave a comment on that specific line — this is how reviewers provide precise feedback. Green lines are new additions, red lines are removed content, and gray lines are unchanged context.
Expected result: You see your open pull request with tabs for Conversation, Commits, and Files changed.
Approve and merge the pull request
Approve and merge the pull request
If you're the one reviewing (or if you're working solo), scroll to the bottom of the Conversation tab. You'll see a green "Merge pull request" button. Click it, then click "Confirm merge." GitHub will take the changes from your feature branch and add them to main. After merging, GitHub will show a "Pull request successfully merged and closed" message and offer a "Delete branch" button — click it to clean up the merged branch since it's no longer needed. If you go back to the Code tab and look at the main branch, you'll see your changes are now included.
Expected result: The pull request shows as "Merged" with a purple icon, and the changes are in main.
Understand what happens when V0 or Lovable creates a pull request
Understand what happens when V0 or Lovable creates a pull request
When you connect V0 to your GitHub repository, it doesn't push directly to main. Instead, it creates a branch (like "v0/main-abc123") and opens a pull request automatically. You'll see this PR appear in your Pull Requests tab. Open it to review what V0 changed — the Files Changed tab shows exactly which files were added or modified. If the changes look good, merge it using the same green button. Lovable typically syncs directly to main with two-way sync, but if you enable branch switching in Lovable Labs, it will create pull requests too. Reviewing AI-generated pull requests helps you stay in control of your codebase.
Expected result: You understand how AI tools create pull requests and how to review and merge them.
Complete working example
1## What does this PR do?23Briefly describe the changes in this pull request.45## Why is this change needed?67Explain the motivation or context for the change.89## What to review1011- [ ] Check the new About page content12- [ ] Verify links work correctly13- [ ] Confirm responsive layout on mobile1415## Screenshots (if applicable)1617Add screenshots or GIFs showing the change.1819## Related issues2021Closes #(issue number)2223## Notes2425Any additional context for reviewers.Common mistakes when understanding What a Pull Request Is in GitHub
Why it's a problem: Merging without reviewing the Files Changed tab
How to avoid: Always click "Files changed" and read through the diff before merging. This is especially important for AI-generated pull requests where the tool may have changed more files than expected.
Why it's a problem: Writing a vague PR title like "Updates" or "Changes"
How to avoid: Be specific: "Add user authentication with Supabase" or "Fix broken navigation on mobile." This helps everyone understand the PR at a glance.
Why it's a problem: Leaving the PR description blank
How to avoid: Always write at least 2-3 sentences explaining what changed and why. Future you (and your team) will thank you when looking back at the project history.
Why it's a problem: Not deleting the branch after merging
How to avoid: Click the "Delete branch" button that appears after merging. Leaving old branches around clutters your repository.
Best practices
- Write clear PR titles starting with an action verb: Add, Fix, Update, Remove
- Always review the Files Changed tab before merging, especially for AI-generated PRs
- Include a brief description explaining both what changed and why
- Use task checklists in the description to track review items
- Delete branches after merging to keep the repository organized
- For team projects, require at least one approval before merging to maintain quality
- Keep pull requests small and focused — one feature or fix per PR
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I'm a non-technical founder learning GitHub. Explain pull requests using a simple real-world analogy. Then describe the complete workflow: creating a branch, making changes, opening a PR, reviewing it, and merging — all using the GitHub web interface, no terminal.
Frequently asked questions
Can I make a pull request to my own repository?
Yes. Even if you're the only person working on a project, pull requests help you organize changes and review your own work before merging. It's a good habit that scales when your team grows.
What happens if I merge a pull request with a mistake?
You can revert the merge. On the merged PR's page, click the "Revert" button to create a new pull request that undoes the changes. This is one of the biggest advantages of using PRs — everything is reversible.
Does V0 automatically create pull requests?
Yes. When V0 is connected to your GitHub repository, it creates a branch and opens a pull request for every batch of changes. You review and merge the PR from the Pull Requests tab on GitHub.
What is a merge conflict in a pull request?
A merge conflict happens when two branches change the same lines in a file. GitHub will show a warning and guide you through resolving it — you pick which version to keep. For complex conflicts, RapidDev can help resolve them without any risk to your codebase.
How many pull requests can I have open at once?
There's no limit. You can have as many open pull requests as you want. However, it's best practice to keep them small and merge them promptly to avoid conflicts.
Can I edit files directly in a pull request?
Yes. On the PR's Files Changed tab, click the three-dot menu on any file and select "Edit file." Your edit will be added as a new commit on the PR's branch.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation