A pull request is how you propose changes to someone else's project on GitHub

A pull request (or PR) is a formal way to say "I've made changes to this code, and I'd like you to review them before adding them to the main project." You create one by pushing your changes to a separate branch, then asking the project owner to compare your branch against theirs. GitHub handles the comparison and lets reviewers see exactly what you changed, line by line.

The person who owns the project (or manages it) can then read your changes, ask questions, request edits, or approve and merge your work into the official version. This process protects the main codebase from broken or untested changes, and it creates a record of who changed what and why.

Key Takeaways

  • You must create a new branch before making changes, then push that branch to GitHub before you can open a pull request.
  • The pull request itself lives on GitHub's website and shows a side-by-side comparison of your changes against the main branch.
  • You write a title and description so reviewers understand what you changed and why, which becomes part of the project's permanent history.
  • The project owner or maintainers review your PR, may ask for changes, and then merge it or close it depending on whether it fits the project's goals.

Create a new branch and make your changes locally

Before you touch any code, create a separate branch. Open your terminal, navigate to your project folder, and run git checkout -b branch-name, replacing branch-name with something short and descriptive — for example, fix-login-button or add-dark-mode. This creates a new branch and switches you to it when ready.

Make your changes in your code editor as you normally would. Test them locally to make sure they work. When you're satisfied, stage your changes with git add . (to add everything) or git add filename (to add specific files), then commit them with git commit -m "Your message here". Write a clear, short commit message that explains what you did — future readers (including yourself) will thank you.

You can make multiple commits on the same branch if your work spans several logical steps. Each commit becomes a separate entry in the pull request, so reviewers can see your thought process.

Push your branch to GitHub

Once your commits are ready, push your branch to GitHub by running git push origin branch-name. The first time you push a new branch, Git may ask you to set the upstream branch; follow the instruction it prints to the terminal.

Go to your GitHub repository in your web browser and refresh the page. You should see a yellow banner near the top saying "Your recently pushed branches" with a button that says "Compare & pull request." Click that button. If you don't see the banner, look for the "Branches" tab, find your branch in the list, and click "New pull request" next to it.

Fill in the pull request title and description

GitHub will show you a form with two fields: a title and a description. The title should be short and say what you did — "Fix login button alignment" or "Add dark mode toggle" work well. Keep it under 72 characters if you can.

In the description, explain why you made the change, not just what you changed (GitHub already shows that in the diff). For example: "The login button was misaligned on mobile devices because the flex container had no gap property. This change adds a 10px gap and fixes the issue on screens under 768px wide." If your change closes an open issue, type "Closes #123" (replacing 123 with the issue number) so GitHub links them automatically.

Some projects have a pull request template that appears in the description box. If one does, fill it out completely — templates exist because the maintainers need specific information to review your work properly.

Review the diff before submitting

Before you click "Create pull request," scroll down and look at the "Files changed" tab. This shows a side-by-side or unified view of every line you added, removed, or modified. Read through it carefully. Did you accidentally include debug code, console.log statements, or changes you didn't mean to make? Now is the time to catch them.

If you spot a mistake, close this form without creating the PR yet. Go back to your terminal, make the fix, commit it, and push again with git push origin branch-name. The form will still be there with your title and description intact, and the diff will update automatically.

Create the pull request and wait for review

Once the diff looks correct, click "Create pull request." GitHub assigns it a number (like #42) and posts it to the project. The project's maintainers will be notified, depending on how they've configured their notifications.

Now you wait. Review times vary — some projects respond in hours, others in days or weeks. While you wait, GitHub will run any automated checks the project has set up (like tests or code style checkers). If those checks fail, you'll see a red X next to your PR. Click on it to see what went wrong, fix the issue locally, commit, and push again. Your PR updates automatically.

Reviewers may leave comments on specific lines of code, asking questions or requesting changes. You can reply to those comments and push new commits to address them. The PR stays open until the maintainers merge it, close it, or ask you to abandon it.

Respond to feedback and make requested changes

If a reviewer asks you to change something, make the change in your local branch, commit it, and push it again. Do not create a new pull request — just push to the same branch. Your existing PR will update automatically with the new commit.

Keep the conversation professional and specific. If you disagree with feedback, explain your reasoning clearly. If you don't understand what a reviewer is asking for, ask a clarifying question. Most open-source maintainers are volunteers and appreciate thoughtful discussion.

Once the maintainers are satisfied, they will click the "Merge" button on the PR. Your code is now part of the official project. GitHub will offer to delete your branch afterward — you can usually say yes, since you won't need it anymore.

Frequently Asked Questions

What if I'm not the project owner — can I still create a pull request?

Yes. If you don't have write access to the repository, GitHub will automatically fork it (create your own copy) when you try to push. You create your PR from your fork back to the original project. The process is the same; the only difference is that your branch lives in your fork instead of the main repository.

Can I create a pull request without pushing my branch first?

No. The pull request compares two branches on GitHub, so both branches must exist on GitHub's servers. You have to push your local branch first, then create the PR on the website.

What does "merge conflict" mean, and what do I do about it?

A merge conflict happens when you and someone else changed the same lines of code in different ways. GitHub will show you the conflicting sections and ask you to choose which version to keep (or combine them manually). Open the conflicted files in your editor, look for the <<<<<<< markers, decide what the code should be, delete the markers, and commit the fix. Push again and the conflict resolves.

Can I create a pull request from the GitHub website without using the terminal?

GitHub's web editor lets you make small changes directly in the browser and create a PR from there, but for anything substantial you'll want to work locally. The web editor is useful for fixing typos or small bugs in documentation, but real development work happens in your terminal and code editor.

What happens if the project owner rejects my pull request?

They'll close it with a comment explaining why. Your code stays in your branch and your fork, but it won't be merged into the official project. You can keep the branch for your own use, or delete it. If you want to try again with a different approach, you can create a new branch and a new PR.