Merging on GitHub combines changes from one branch into another, usually from a feature branch into main. You do this through a pull request (PR): go to the Pull requests tab, click "New pull request," select your branch, review the changes, then click "Create pull request." After review, click the green "Merge pull request" button. GitHub offers three merge methods — merge commit, squash and merge, and rebase and merge — each organizing history differently.
Pull Requests — The Safe Way to Merge Changes
A pull request (often abbreviated PR) is GitHub's way of saying: "I made some changes on a branch and I would like to merge them into another branch." It is called a "request" because it gives you (and your team) a chance to review the changes before they become part of the main codebase. The pull request page shows a diff — a line-by-line comparison highlighting what was added (in green) and what was removed (in red). Reviewers can leave comments, suggest changes, and approve the PR before it is merged. When you click the merge button, GitHub offers three options: a merge commit (preserves all individual commits), squash and merge (combines all commits into one), and rebase and merge (replays commits on top of main). For most non-technical users, "squash and merge" is the simplest choice because it keeps the history clean. If you are using AI tools like Lovable or V0 that push code to GitHub, their changes often come as pull requests too, and understanding how to review and merge them gives you control over what goes into your live project.
Prerequisites
- A free GitHub account (sign up at github.com)
- A repository with at least two branches (main and a feature branch with changes)
- Write access to the repository
Step-by-step guide
Navigate to the Pull requests tab
Navigate to the Pull requests tab
Go to your repository on github.com. Click the "Pull requests" tab in the top navigation bar (between "Issues" and "Actions"). This page shows all open pull requests. If someone has already created a PR for the branch you want to merge, click it and skip to the review step. Otherwise, you will create a new one.
Expected result: You are on the Pull requests page showing a list of open PRs (possibly empty).
Create a new pull request
Create a new pull request
Click the green "New pull request" button. GitHub shows a comparison page with two dropdowns: "base" (the branch you want to merge into, usually main) and "compare" (the branch with your changes). Click the "compare" dropdown and select your feature branch. GitHub loads the diff showing all changes between the two branches — added lines in green, removed lines in red. Review the changes to make sure everything looks correct.
Expected result: You see a diff view showing all the changes your branch introduces compared to main.
Fill in the pull request title and description
Fill in the pull request title and description
Click the green "Create pull request" button at the top of the diff. A form appears with a title field (pre-filled with your branch name or latest commit message) and a description field. Write a clear title like "Add pricing page with Stripe integration" and a description explaining what changed and why. If you are working with a team, mention who should review it. Click "Create pull request" to submit.
Expected result: The pull request is created and you land on the PR page showing the title, description, diff, and merge options.
Review the changes in the Files changed tab
Review the changes in the Files changed tab
Click the "Files changed" tab on the PR page. This shows every file that was modified, with additions in green and deletions in red. Scroll through each file to confirm the changes are correct. If you spot something wrong, you can click the pencil icon on any file in the diff to edit it directly. You can also leave comments on specific lines by clicking the blue + icon that appears when you hover over a line number.
Expected result: You have reviewed all changed files and are satisfied the changes are correct.
Choose a merge method and merge the pull request
Choose a merge method and merge the pull request
Go back to the "Conversation" tab on the PR page. Scroll down to the green merge area. Click the dropdown arrow next to the green "Merge pull request" button to see three options: "Create a merge commit" (keeps all individual commits in the history), "Squash and merge" (combines all commits into a single one — recommended for clean history), and "Rebase and merge" (replays each commit on top of main). Choose your preferred method, then click the green button. Confirm by clicking "Confirm merge" (or "Confirm squash and merge").
Expected result: The PR shows a purple "Merged" banner. The changes are now part of the main branch.
Delete the branch after merging
Delete the branch after merging
After the merge completes, GitHub shows a "Delete branch" button below the merged banner. Click it to clean up the branch that was just merged. The code is safely in main now, so the branch is no longer needed. If you change your mind, a "Restore branch" button appears.
Expected result: The branch is deleted and the repository is clean with all changes on main.
Complete working example
1## What does this PR do?23<!-- Describe the changes in 1-3 sentences -->45## Why is this change needed?67<!-- Explain the problem this solves or feature this adds -->89## Changes made1011- [ ] Added new files12- [ ] Modified existing files13- [ ] Deleted files14- [ ] Updated configuration1516## Screenshots (if applicable)1718<!-- Drag and drop screenshots here -->1920## How to test21221. Switch to this branch232. Navigate to the changed page243. Verify the feature works as expected2526## Checklist2728- [ ] I reviewed my own changes in the Files changed tab29- [ ] The changes work on mobile and desktop30- [ ] No sensitive data (API keys, passwords) is included31- [ ] The commit message clearly describes the changeCommon mistakes when merging Changes Using Pull Requests in GitHub
Why it's a problem: Merging without reviewing the changes first
How to avoid: Always click the Files changed tab and scroll through every modification before merging. Even a quick scan can catch accidental deletions or wrong values.
Why it's a problem: Not understanding the difference between merge methods
How to avoid: Use "Squash and merge" for most situations — it creates one clean commit. Use "Create a merge commit" if you want to preserve the full commit-by-commit history.
Why it's a problem: Ignoring merge conflicts and hoping they go away
How to avoid: GitHub shows a "Resolve conflicts" button when there are conflicts. Click it to open an editor where you choose which version of conflicting lines to keep.
Why it's a problem: Merging a pull request from an AI tool (like V0) without reviewing the code
How to avoid: AI tools can introduce unexpected changes. Always review the Files changed tab before merging any automated PR.
Best practices
- Always review changes in the Files changed tab before merging any pull request.
- Use "Squash and merge" as the default to keep your main branch history clean and readable.
- Write descriptive PR titles and descriptions so you can understand changes weeks later.
- Delete branches after merging to prevent stale branch accumulation.
- Enable "Automatically delete head branches" in Settings to auto-clean after every merge.
- For team projects, require at least one approval before merging (Settings → Branches → Branch protection).
- Add a pull request template to standardize how team members describe their changes.
- Review AI-generated pull requests (from Lovable, V0, Cursor) with extra care — automated code can contain unexpected changes.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I have a pull request on GitHub with 12 files changed. How do I review it effectively as a non-technical person? What should I look for to make sure the changes are safe to merge?
Frequently asked questions
What is a merge conflict and how do I fix it?
A merge conflict happens when two branches change the same lines of a file differently. GitHub shows a "Resolve conflicts" button on the PR page. Click it to open an editor that shows both versions. Delete the version you do not want (and the conflict markers), then click "Mark as resolved" and "Commit merge."
Can I undo a merge after it is done?
Yes. On the merged pull request page, click the "Revert" button. GitHub creates a new pull request that undoes all the changes from the original merge. Merge the revert PR to undo the original changes.
Which merge method should I use?
For most projects: Squash and merge. It combines all branch commits into one clean commit on main. Use Merge commit if you want the full commit-by-commit history preserved. Rebase and merge is for advanced users who want a linear history without merge commits.
Do I need to merge pull requests from Lovable or V0?
Lovable syncs directly with main, so you typically do not create PRs. V0 creates a branch and opens a PR when you connect via GitHub — you review and merge that PR to bring V0 changes into main.
Can I merge without a pull request?
Technically yes — you can commit directly to main when editing files. But pull requests give you a chance to review changes, add comments, and maintain a record of what was merged and why. They are strongly recommended.
Can RapidDev help me review and merge pull requests?
Yes. RapidDev helps non-technical founders review code changes, resolve merge conflicts, and set up branch protection rules so that nothing gets merged without proper review.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation