This branched out from my previous question: Can I select who can contribute to my Open Source Project?

Having never worked on open source software before, and developing my own mini applications that I hope to release to the App Store sometimes this summer, I'm quite unfamiliar with the way most open source development structures are set up (forks, main repositories...).

One thing that popped up was the mention of a pull request. What exactly is a pull request?


If you have distributed version control systems, every developer has a copy of the full repository. If you change something to the software, you commit your changes to your local repository. If different repositories should have these changes, you can push the changes (moving changes to another repository you have the right to write to) or pull the changes (copy revision from other repositories to your own). As many project have a main repository, a pull-request is the request that the maintainer pulls your changes.

Reading up a bit on it, it seems the term is used also on non-distributed version-control, if one user ask for inclusion of his patches in the main branch of the project. Another read especially for github: https://help.github.com/articles/using-pull-requests/


The term "pull request" comes from git, where the git pull command is used to merge a different repository into your local one. So if someone else has a copy of your git repository, and makes changes to it that they would like you to incorporate, they can ask you to pull the changes from their repository; they're requesting a pull, hence the term "pull request".

Nowadays for most users this tends to be hidden behind a graphical interface of some sort, on Github or Bitbucket or via Gerrit for example; but the principle remains the same: someone copies your repository, makes changes and requests them to be merged into your own copy, presumably after you've reviewed them.

  • 2
    Git also has a git request-pull command. This produces a written message that you can send to someone else, inviting them to use git pull to incorporate your work into their copy of the software. – bdsl Mar 16 '16 at 15:45

A pull request is related to version control systems. You may have several sets of users:

  • Administrators/Owners
  • Contributors
  • Testers

You want each of these people to be able to do different things:

  • Administrators/Owners
    These people can be trusted. They might have full access to the repository in question, including full rights to commit what they want when they want.
  • Contributors
    These might be random people from the Internet; they might be lesser people in a company. Either way, you probably don't want them to be able to commit straight to the codebase - you want to review their changes first.

This is where pull requests come in. Instead of allowing straight changes to the codebase from your contributors, they will instead fork the repository, creating a copy on their local machine, and develop that. When they're done, they can create a pull request containing their updated code. Someone in the higher group can then review their changes for correctness and complicity with standards, and merge their changes if they comply.

  • 1
    Slightly off topic, but even those people who can directly merge their own changes should submit PRs for their peers to review. Assuming you're working on a team that is. If you're not, I guess that's what CodeReview is for. – RubberDuck Aug 7 '15 at 0:20

A pull request (PR) is a method of submitting contributions to an open development project. It occurs when a developer asks for changes committed to an external repository to be considered for inclusion in a project’s main repository after the peer review.

Source: What Is A Pull Request? at OSS Watch

Simple example is when you clone/fork the open source repository, do some changes/commits and in order to merge the changes into the main repository, you are required to send the pull request which consist all your commits grouped into one logical piece so it can be reviewed by other developers.

This has some benefits over standard commits and pushes as you have some additional pair of eyes to check and avoid common/hidden issues/mistakes before the actual changes.

See few PR examples:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.