Git Pull Request: What It Is, How It Works, and How to Create One

git-pull-request-explained.jpg
Key Takeaways:
  • A pull request (often abbreviated as “PR”) is a proposal to merge changes from one branch into another in a Git repository.
  • Pull requests are not Git native commands but rather a feature of Git hosting platforms, such as GitHub, GitLab, or Bitbucket.
  • They allow developers to review, discuss, test, and approve code before merging it into the main codebase.
  • PRs maintain code quality, support automated testing through CI/CD. Moreover, they supply a clear version history.
  • GitHub uses “Pull Requests” (PR), while GitLab refers to them as “Merge Requests” (MR).
  • Pull requests promote transparency, accountability, and teamwork in software development.

In collaborative software development, tracking changes isn’t enough. You need to be able to review, discuss, and merge them safely back into your main codebase. This is where Git Pull Requests come into play.

A Git Pull Request (PR) plays a key role in modern Git workflows, especially on platforms like GitHub and Bitbucket. Although pull requests aren’t native to Git, major Git hosting services often include them as a feature to foster collaboration between team members. GitLab has a similar feature, called a Merge Request.

In this tutorial, we will discuss what a Git Pull Request is, how it works, how to create one, and how it differs from other Git operations. We will also learn best practices to help keep your team’s development process clean, efficient, and maintainable.

Table of Contents:

What Is a Git Pull Request?

A Git pull request is a medium to request the code reviewer that the changes you made in one branch of a project be added to another branch, which is usually the main repository. You don’t create a pull request using regular Git commands. Instead, you use platforms like GitHub, GitLab, or Bitbucket, which offer this feature to make teamwork and code review easier.

“Pull Request (PR) is a formal, reviewable merge proposal to merge new changes to the main branch that you made in a local branch.”

It allows you to contribute to another person’s git repository. When you submit a pull request, a maintainer is notified and asked to review the code you wish to incorporate into their repository. If you are working on some piece of functionality, then it is better to be transparent in informing every team member about any changes you make in the code. A pull request guarantees that contributions will be effectively merged into the project’s main code tree.  

what_is_a_git_pull_request

A pull request displays:

  • The differences between branches.
  • Any conflicts.
  • Place to discuss and review the code with teammates.

Why Use Pull Requests?

Pull requests offer several benefits, as unlike a direct merge, a pull request gives your team a chance to:

1. Review Code Changes 

It allows peer code reviews, identifying bugs and issues, and suggesting areas for improvement before merging new code.

2. Collaborative Suggestions

Pull requests provide a platform to discuss and provide feedback, where team members can comment on the code and design approach and have discussions that support collaboration. The use of pull requests fosters knowledge sharing between team members. 

3. History Tracking

By working in a separate branch and making the changes, when we raise a pull request, it makes sure the commit history is clear, and tracking down or even reverting back changes is easy.

4. Run Automated Tests (CI/CD)

A pull request can be easily integrated with CI/CD (Continuous Integration/Continuous Deployment) pipelines to run tests and checks on the code changes automatically. This ensures that the merged code has passed all checks before merging.

5. Prevent Regressions via Approval Rules

The review and approval process before merging helps mitigate the risk of introducing errors into the main codebase.

Note: A PR doesn’t execute the actual git pull command; rather, it’s a request for maintainers to review and pull your changes into the main branch.

How Git Pull Requests Work?

Here’s what happens when you create a pull request:

1. Create a Feature Branch: 

When a developer starts working on a new feature or bug fix, they create a new branch off from the main branch. This helps isolate their changes and avoid affecting the main codebase.

2. Develop and Commit Changes: 

The developer makes the necessary modifications in their feature branch and commits locally. These commits capture the progress and updates made to the code.

3. Push the Branch to the Remote Repository: 

After the local changes are done, we push our branch to a remote repository like in GitHub or GitLab. This makes the changes accessible to others.

4. Open a Pull Request: 

The developer then opens a pull request (PR) to suggest merging their feature branch into the target branch, typically main. The description of changes that are made is mentioned on the pull request with its intentions.

5. Code Review Begins:

Team members are notified and begin reviewing the code. They can give feedback, request changes, or ask questions directly inside the PR conversation thread.

6. Addressing Feedback:

If any changes are requested, the developer updates the feature branch by committing additional code. The PR is automatically updated with these new commits.

7.CI/CD Pipeline Runs (If Configured):

If the project uses CI/CD tools, the pipeline will run automated tests and checks every time new commits are added to the PR. This ensures that the changes don’t break existing functionality.

8. Merge the Pull Request: 

Once the PR passes all checks and is approved by the reviewers, it can be merged into the target branch. This integrates the new code into the main project.

9. Clean Up the Branch: 

After a successful merge, the feature branch can be safely deleted both locally and remotely to keep the repository clean.

how_git_pull_requests_work

This git pull request workflow provides visibility, reviewability, and control.

How To Create a Pull Request on GitHub

A pull request allows you to send the owner of a repository a request to pull in your new code changes. These changes could be anything from adding or improving a feature to perhaps fixing a bug. 

git_pull_request_flow_diagram

Let’s go through a real-world workflow using GitHub for a git pull request example.

Step 1: Find and Fork the Repository

  • Go to the GitHub repository you want to contribute to.
  • Click the “Fork” button on the top right to create a copy under your GitHub account.
Find and Fork the Repository
  • We’re using a basic example for this demo containing one file called hello.py, and it just prints ‘hello world’ to the console. 
  • The next step is to fork your project. 
fork your project
  • This would create an exact copy and store it in your GitHub account, so any changes made here will not affect the original code.
new fork

Step 2:  Clone the Fork to Your Local Machine

Currently, our copy only exists on GitHub, so we need to pull it onto our local machine so we can start making changes. 

Clone the Fork to Your Local Machine
  • Copy the HTTPS link from the right side, where you can find a dropdown named “code”, and copy the link and go to your terminal. In this example code, we are using git bash.
git clone
  • Type git clone and paste the link you just copied, then change the directory into the project. 

Step 3. Create a New Branch

  • The next step is to create a working branch off of main. To do this in one command, you type ‘git checkout -b’ and then give your branch a name, “new branch”.
Create a New Branch

Step 4. Make the Changes 

  • We will use the vim command as shown in the image, and we’ll change the print statement in the file hello.py from ‘hello world’ to ‘hello Intellipaat.’
Make the Changes
hello

Step 5. Stage and Commit the Changes

  • git status # to check modified files
  • git add hello.py # stage the file
  • git commit -m “Updated print statement”

Now that we’ve committed all our changes locally, it’s time to push our code back to GitHub.

Stage and Commit the Changes

Step 6. Push the Branch to GitHub

  • To push the code run ‘git push’.
  • Since new branch doesn’t yet exist on GitHub they provide the command ‘git push – -set -upstream origin new_branch’. 
Push the Branch to GitHub

Step 7. Open a Pull Request on GitHub

  • Go to your forked repository on GitHub.
  • Click on the “Pull requests” tab.
  • Click “New pull request”.
  • On the left, choose the branch from the original repo you want to merge into (usually main).
  • On the right, select your newly pushed branch (e.g., new_branch).
Open a Pull Request on GitHub
compare and pull request.jpg
  •  Click “Compare & Pull Request” button.
  • Add a title and description of your changes.
  • Click “Create Pull Request” to submit.
Create Pull Request
open a pull request

Step 8: Review and Merge

  • The repository owner (or team) will review your PR.
  • They can comment, request changes, or approve it.
  • Once approved, they’ll merge it into the main branch.
Review and Merge
confirm merge
created a pull request

Congratulations, you have successfully created a pull request and contributed to an open source project. 

Creating a Merge Request using GitLab 

The steps are literally same though the term used here for Pull Request (PR) will be Merge Request (MR).

  1. Push your feature branch:
    git push origin feature-branch
  2. Navigate to your project repository on GitLab.
  3. Go to the Merge Requests tab.
  4. Click New Merge Request.
  5. Choose your source branch (feature branch) and your target branch (e.g. main).
  6. Provide a title, description, assign reviewers, and optionally link issues or set labels.
  7. Click Create Merge Request. Review and CI information is then visible within the MR.

Common Issues with Pull Requests

Even though pull requests streamline workflows, they aren’t free from bugs. Here are some common issues with git pull requests.

1. Merge Conflicts

You will get the conflict if both branches modified the same lines of code.  GitHub will highlight it for you to resolve and commit the fix manually.

2. Failing CI Tests

Automated checks will fail if your PR breaks a build or test. Always test locally before pushing.

3. Reviewer Feedback Loops

Long PRs can take days of back-and-forth. To avoid this, break features into smaller, reviewable PRs.

Best Practices for Git Pull Requests

To keep your team productive and happy:

  1. Write meaningful PR titles
  2. Keep PRs small and aim for 100–200 lines if possible
  3. Describe your changes clearly, use checklists, and links to issues
  4. Avoid force-pushing once review starts
  5. Tag relevant reviewers only

Benefits of Using Pull Requests

Pull requests offer several advantages, including facilitating code review and collaboration, ensuring code quality through automated tests, and providing a clear history of changes. They also enhance transparency by showing what changes are being made.

Git Pull Request vs Git Merge vs Git Pull 

These Git terms sound similar but serve different purposes. Here’s how they compare:

Command / Action Purpose Where It Happens
git merge Combine changes from one branch into another Local or remote
git pull Fetch + merge updates from the remote repository Local machine
Pull Request (PR) Propose + review + merge changes via interface GitHub/GitLab/Bitbucket
Note: A pull request is not a Git command but a hosted feature enabling safe merges and collaboration.

Git Pull Request Commands 

There’s no native git pull-request command in Git itself, but some tools let you open PRs from your terminal. These tools integrate with GitHub and automate the PR process.

  1. GitHub CLI (gh)

This is the recommended way to create pull requests via terminal for GitHub repositories.

gh pr create --base main --head feature/update-ui --title "Update UI" --body "Improved layout and colors"

–base main: The branch you want to merge into

–head feature/update-ui: The branch you are merging from

–title and –body: Title and description of the PR

  1. Hub (deprecated)

The older hub tool used to allow similar functionality but is no longer maintained.

hub pull-request -m "Update UI layout"

Conclusion

Pull Requests aren’t just about merging code; they are also about the discussion, quality control, and having a clean and organized codebase. It doesn’t matter if you’re working alone or with a global team; proficiency in Git Pull Requests will help you to work better.

Now that you know what a Git Pull Request is and how to use it, next time there’s a feature or bug fix release, give this method a go!

Git Pull Request – FAQs

1. What is a Git pull request?

A pull request for a Git is a request to propose changes in one branch and merge them into another, where approval must be taken before integration.

2. How do I create a pull request in Git?

To make a pull request, first push your branch to any remote that supports git, like GitHub, and then open up a PR using the platform’s interface.

3. How do I resolve conflicts in a PR?

When you have conflicts in a pull request, you will want to look for the files with conflicts, edit them using your code editor or merge tool, and then commit the changes.

4. Can I change a pull request after opening it?

Yes, after opening a pull request you can change it. Pull requests are designed to be flexible and may be modified as necessary during the review process.

5. Who should review a PR?

A Pull Request (PR) should be reviewed by a team member who is familiar with the codebase and the changes being proposed.


About the Author

Senior Associate - Digital Marketing

Shailesh is a Senior Editor in Digital Marketing with a passion for storytelling. His expertise lies in crafting compelling brand stories; he blends his expertise in marketing with a love for words to captivate audiences worldwide. His projects focus on innovative digital marketing ideas with strategic thought and accuracy.

Advanced Data Science AI