How to Create a Pull Request in GitHub

Pull requests are one of the most important workflows in collaborative software development — and understanding how they work can make the difference between chaotic code management and a clean, reviewable history. Whether you're contributing to an open-source project or working with a small team, knowing how to create a pull request correctly is a foundational GitHub skill.

What Is a Pull Request?

A pull request (PR) is a formal way of proposing changes to a codebase. When you create a pull request, you're asking the repository maintainer (or your team) to review your changes and — if everything looks good — merge them into another branch, typically the main or develop branch.

Think of it less like "pushing code" and more like submitting a piece of work for review before it becomes official. The PR creates a dedicated space for discussion, inline comments, revision requests, and approval tracking.

Before You Create a Pull Request: The Setup

You can't create a meaningful pull request without a separate branch containing your changes. The standard workflow looks like this:

1. Fork or clone the repository
2. Create a new branch off the base branch (main, dev, etc.)
3. Make your changes — code edits, file additions, bug fixes
4. Commit your changes with clear, descriptive commit messages
5. Push the branch to GitHub

If you skip the branching step and commit directly to main, there's nothing to compare — and no clean way to review or roll back changes without affecting the whole project.

Step-by-Step: Creating a Pull Request on GitHub 🔀

Step 1: Push Your Branch to GitHub

After committing your changes locally, push the branch to the remote repository:

git push origin your-branch-name 

Once pushed, GitHub will often display a prompt at the top of the repository page suggesting you create a pull request from the recently pushed branch.

Step 2: Open the Pull Request Interface

Navigate to the repository on GitHub. Click the "Pull requests" tab, then click "New pull request".

You'll be asked to choose:

• Base branch — the branch you want to merge into (usually main)
• Compare branch — the branch containing your changes

GitHub will automatically show a diff of all changes between the two branches.

Step 3: Review the Diff

Before submitting, scan the diff view carefully. This shows every line added (in green) and removed (in red). It's worth checking here for:

• Accidental file inclusions (e.g., local config files, credentials)
• Unfinished code or debug statements left in
• Merge conflicts flagged by GitHub

Step 4: Fill In the PR Details

This step matters more than most people realize. A good pull request includes:

• A clear title — summarizes what the PR does (e.g., "Fix login timeout bug on mobile devices")
• A description — explains why the change was made, not just what changed
• References to issues — if you're resolving a tracked issue, use Closes #42 syntax to auto-link and close it on merge
• Screenshots or logs (optional) — especially useful for UI changes or bug fixes

Many teams use PR templates — a pre-filled description format in the repository that guides contributors on what to include.

Step 5: Assign Reviewers and Labels

If you have write access or are on a team, you can:

• Assign reviewers who will be notified to check the code
• Add labels like bug, enhancement, or work in progress
• Link a project or milestone for project management tracking

For open-source contributions where you don't control the repository, you skip this step — the maintainer assigns reviewers themselves.

Step 6: Submit the Pull Request

Click "Create pull request". Your PR is now live and visible to collaborators. GitHub will run any configured CI/CD checks (automated tests, linting, etc.) and display their status directly on the PR page.

What Happens After Submission

Once submitted, reviewers can:

• Leave inline comments on specific lines of code
• Request changes before approving
• Approve the PR and merge it

If changes are requested, you don't need to close and reopen the PR. Simply make additional commits to the same branch — they'll automatically appear in the open PR.

Merge options vary and affect your repository's commit history differently:

Which option is appropriate depends on your team's branching strategy and how much commit history granularity matters to your project.

Variables That Affect the Process 🔧

The pull request process looks different depending on several factors:

• Repository permissions — contributors without write access must fork first; team members can branch directly
• Branch protection rules — some repositories require a minimum number of approvals, passing CI checks, or specific reviewer sign-offs before merging is allowed
• Team conventions — some teams require squash merges; others preserve full history
• PR size — a single-file change is reviewed very differently from a 50-file refactor

Open-source projects often have detailed contributing guides that specify exactly how PRs should be structured and submitted. Internal team repos may have their own workflows enforced through GitHub's branch protection settings.

Whether you're a solo developer contributing to a public project or part of a large engineering team, the mechanics are consistent — but the rules, expectations, and review dynamics around those mechanics vary considerably from one repository to the next.