Pull Request in Git: Your Guide to How It Works

Pull requests have helped my teams avoid bugs, align on implementation decisions, and learn from each other’s code. In this guide, I will show you how to use pull requests in Git-based platforms to review your code safely.

If you are getting started with Git, I recommend taking our Introduction to Git and Introduction to GitHub Concepts courses to learn about version control and the differences between Git and GitHub. Also, I find the Git Cheat Sheet, which you can download, is a helpful reference because it has all the most common Git terminologies and commands.

What Is a Pull Request?

A pull request is really a method to suggest changes to code. So imagine you're working on a feature or in a separate branch, a pull request lets you ask to merge those changes into the main codebase. This is usually done after others have had a chance to review them. Pull requests are a core part of collaborative development, especially when working in teams.

It’s worth noting that on GitLab, the same process is called a “Merge Request.” 

How Does a Pull Request Work?

The following steps outline the basic workflow of a pull request:

1. Make changes to the script (code) in a feature branch.
2. Commit these changes in your local repository.
3. Push the branch to the remote repository such as GitHub.
4. Open a pull request to suggest the changes to the main branch.
5. Request a review for the proposed changes.
6. Merge or close the pull request depending on the outcome.

This workflow gives every developer a chance to review code and identify potential issues before pushing code for live production.

The key roles in the pull request process include the following:

• Contributor: The developer who makes changes and opens the pull request.
• Reviewer: This is the developer who reviews the proposed code changes to suggest improvements and ensure code quality.
• Maintainer: The Project manager who owns the project and has the permission to approve or reject pull requests. 

I recommend taking our Intermediate Git course to learn how to create branches in Git and how to collaborate with team members remotely.

Creating a Pull Request (with an Example)

Let’s say you notice an error in the introduction line of your project’s README file. You want to fix this issue without affecting the main branch. Follow the steps below:

Step 1: Create a new branch

Navigate to your project’s folder and open the terminal to run the command below. This line creates another branch.

git checkout -b fix-readme-typo

Step 2: Make your change

To correct the file, open the README.md in your code editor, correct the typo, then save the file.

Step 3: Commit the changes

Stage and commit the changes using the command below:

git add README.md
git commit -m "Fix typo in README"

Step 4: Push the branch to GitHub

Upload the branch to the repository.

git push origin fix-readme-typo

Step 5: Open GitHub and create a pull request

Now open your GitHub account and do the following:

• Navigate to your repository on GitHub.

• Select the prompt Compare & pull request for your pushed branch.

• Add a title like Fix typo in README and optionally write a short description.

• Choose your base branch (usually main) and compare it with your feature branch.

Step 6: Request review and submit

If your project involves other developers, you can request reviewers or add labels if the project uses them. Then click Create pull request.

Check out our project on Performing a Code Review to understand how to review and make changes before pushing code to production.

Pull Request Best Practices

The following are the best practices to ensure quality development when creating pull requests:

• Keep your pull requests tight and simple: Always begin with one pull request for every feature that you'd like to suggest. This helps the reviewer track and test your alterations and minimizes the possibility of introducing a bug.
• Write clear commit messages and descriptions: Provide descriptive commit messages to explain the edits. This context helps reviewers understand your intent without digging through the code.  
• Take advantage of draft pull requests for early feedback: If your work is not complete but you want feedback, create a draft pull request. It indicates that your code is a work in progress and solicits discussion with no obligation to merge immediately.
• Test thoroughly and share context: Always double-check your changes to make sure that everything works like you expect.

Pull Requests Across Git Workflows

Here’s a quick overview of how different team settings use pull requests.

• Feature branching: This is common in small teams and private repositories. This workflow involves creating a new branch for each feature. 

• Forking workflow: This workflow is used in open-source projects. The forking workflow requires contributors to fork (copy) the main repository into their account. They make changes in their fork and then open a pull request to the original.

• GitFlow: This is a structured workflow that uses long-term branches like main, develop, release, and hotfix. It’s used by larger teams with more involved release cycles.

Pull Request Etiquette

It’s possible to have bad manners, so pull requests come with their own kind of etiquette:

• Be respectful and specific: Focus on the code, not the individual.
• Keep pull requests focused: Avoid mixing unrelated changes in one pull request. Igorning this just complicates the review and feedback.
• Respond thoughtfully to feedback: Acknowledge well-written code and suggestions for improvement.
• Don’t let pull requests sit too long: Always try to review and resolve pull requests as quickly as possible to avoid delaying updates.
• Ask questions: If something isn’t clear, ask for clarification rather than assuming intent to help avoid misunderstandings.
• Suggest Improvements: Where appropriate, offer actionable advice or alternative approaches rather than only pointing out issues.

Advanced Pull Request Workflows and Best Practices

If you’re an experienced developer wanting to make collaboration smoother, boost code quality, and scale your pull request process, here are some practical tips to sharpen your workflow.

Smarter workflows

Various Git workflows handle pull requests differently. As we discussed earlier, Feature branching is ideal for small teams because of its simplicity. However, it can become challenging to maintain if you have a growing team.

Forking is recommended for open-source projects but may introduce overhead in syncing and reviewing external contributions. Similarly, GitFlow is recommended in fast-paced development, although its complexity can slow down the process. 

Automation and integration

Modern pull requests have the CI/CD Checks, which automate quality gates by integrating continuous integration tools that run tests and linters and deploy previews on every PR. This ensures only code that passes defined standards gets merged.

Platforms like GitHub Actions and GitLab Pipelines also enable automation. These processes include running unit tests, building and deploying preview environments, reducing manual effort and catching issues early.

Optimizing reviews

Always keep pull requests small and focused so that they can be reviewed quickly and thoroughly. Using templates with clear fields such as “What changed” and “How to test” helps contributors provide concise, relevant information, making reviews more efficient.

You should also note that asking questions rather than making demands fosters constructive dialogue and learning. If you define turnaround times for reviews, you will keep the process predictable and avoid delays.

Metrics and modern tools

I also recommend that you track PR size, time to review, and merge rate to identify bottlenecks and improve workflow efficiency. To make reviews and merging easier, try using a stacked pull request. This would break big features into smaller, connected PRs that build on one another. 

Besides, you can integrate AI tools like GitHub Copilot or CodeWhisperer when using pull requests. These tools will help you highlight potential issues early enough and suggest how to correct them.

Pull Requests vs. Merge Requests

In GitHub and GitLab, Pull Requests (PR) and Merge Requests (MR) are used interchangeably. Although they serve the same purpose, each platform handles them differently.

The table below compares PRs and MRs to highlight these differences.

Conclusion

Pull requests are a must-know thing for any serious project. As you seen (and I hope you now appreciate) they allow teams to review and discuss and enhance code collaboratively.

Keep enhancing your skills as a developer. Check out our Git Fundamentals and GitHub Foundations skills tracks to become an expert in all things Git.