The terminology used to merge a branch with an official repository is a 'pull request'. This is confusing, as it appears that I am requesting to push my changes to the official repository.
Why is it called a pull request and not a push request?
565
votes
13 Answers
500
votes
If you have a code change in your repository, and want to move it to a target repository, then:
- "Push" is you forcing the changes being present in the target repository (
git push). - "Pull" is the target repository grabbing your changes to be present there (
git pullfrom the other repo).
A "pull request" is you requesting the target repository to please grab your changes.
A "push request" would be the target repository requesting you to push your changes.
105
votes
44
votes
tl;dr since I am not allowed to make a push, I'll just nicely make a request to the repo owner so they decide to pull
Who can push code to a repository?
Should anyone (possibly evil or uneducated or unknown) be able to come and say here I just pushed this to your master branch and messed up all your code HAHAHA! ?
Surely you don't want him to do that. By default a safety net is set so no one can push to your repo. You can set others as a collaborator, then they can push. You would give such access to people you trust.
So if you're not a collaborator and try to push, you will get some error indicating you don't have permission.
So how can other developers push to a repo they are not given permission to push?
You can't give access to everyone, yet you want to give others an outlet/entry point so they can make 'a request to the repo owner to pull this code into the repo'. Simply put by making the repo accessible, they can fork it...make their changes in their own fork. Push their changes to their own fork. Once it's in their in their own remote repo:
They make a pull request from their fork and the owner of the upstream repo (which you can't push directly to) will decide whether or not to merge the pull request.
To explain it from a different angle:
pushing is for things you don't need anyone's approval e.g. you can always push to a feature branch that you've created yourself and have been committing to.
While you can create a pull request between two branches you've created yourself and can push onto. You almost never do that.
I've done that though when I was working on a big feature and already approvals on my pull request, but needed to make a tricky change, so I created a PR against my existing branch.
If you then need approval, then you don't want to push. You want others to:
- review your branch
- give you approvals
- fetch your branch
- merge it with master
(3+4 = git pull)
Also a semi-related question I recommend reading What exactly happens in a git push? Why isn't a git push considered just like a git merge?
6
votes
I want to push something to someone else's repo.
I do not have the permission to push (or pull, for that matter).
The owner/collaborators has permissions. They can pull as well as push. I cannot push.
So, I request them to perform a pull from me - which indirectly means that I am requesting them to accept my push.
So, no request for push. Only for a pull. And for acceptance of a push.
Hence, a 'pull' request. And not a 'push' request.
5
votes
I'm afraid that most of these answers address the question What does 'pull request' mean? or What would 'push request' mean? rather than the OP's question: Why is it called a pull request and not a push request?
Normally this sort of question-replacement is acceptable, but in this case it is clear that the OP knows the answers to these replacement questions, so answering them is not very helpful.
Only the people at GitHub that coined the term know for sure. However it seems evident that this terminological choice reflects something like the following viewpoint concerning the phenomenon of "changes coming in to a repository from outside": The maintainer does the action (pull).
However, a request is also an action, and the doer of that action is not the maintainer but rather the submitter (who has done even more action, namely work). Thus the term 'pull request' creates confusion about who the agent is. Ultimately the confusion arises because of the recursive nature of a request: A request is both an action by a primary agent and a request for a future action by a second agent.
The situation is quite analogous to now-common linguistic constructs like "we built our house" (used in place of "we paid someone else to build our house"), in that responsibility for the primary action is shifted from the obvious original agent to a secondary agent fulfilling a managerial social role.
One might conclude from this that the reason for the terminological choice is legitimization of the viewpoint that managerial work is first-class labor. Moreover the reason for confusion about this terminological choice may be that non-manager workers naturally have a different viewpoint.
4
votes
2
votes
To understand this better and remember it forever, you need to picture it.
Picture a big, living tree {as your repository}. The tree is too sturdy for you to push a branch into in or add a new part into it {symbolizes creating a new branch or you pushing code in it}, instead you must ask the tree to pull a branch into the trunk or have the changes from you.
The term “pull requests” comes from the distributed nature. Instead of just pushing your changes into the repository (like you would do with a centralized repository, e.g. with Subversion), you are publishing your changes separately and ask the maintainer to pull in your changes. The maintainer then can look over the changes and do said pull.
So you basically "request" the guys with writing access to the repo you want to contribute to, to "Pull" from your repo.
Pull requests let you tell others about the changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch. Github Explanation
1
votes
It's not only about subjective and objective. It is also logical to say "I request to push" if it is actually a push operation lying behind.
The major reason is that you cannot push to others' repo. Instead, you have to request them to pull your branch.
So, why doesn't GitHub allow you to request to push? Intuitively, this kind of approach also makes sense if the managers are able to choose to accept or refuse my push, just as how they choose to accept or refuse to pull my repo.
Let's look at push first. Say, there are two repos, A and B:
repo A： repoB：
b c
| |
a a
A and B have commit b and c on commit a, respectively.
Then you push from A to B. There are two kinds of results.
- You
git pushand fail. Because A and B conflict. - You
git push --forceand success. However, commit c is gone. It becomes
repo A： repoB：
b b
| |
a a
This is what you want to do, right? So you need to do it other way.
You have to eliminate the conflications before a push. Say, you have to pull the upstream repo first and get
repo A： repoB：
d
|\
b c c
|/ |
a a
And then you are able to push.
This is how a push request system looks like: contributors handle the conflictions first and request to make a push operation to change the upstream repo. Maybe it seems neat now. The manager of the upstream repo can choose to accept or refuse contributors' push request. Everything works.
However, it only works if there's no other push request.
Say you have just make a push request after pulled the upstream branch and handled the conflictions. You think you are done, but no, in fact. You surprisedly find that the owner of the upstream repo just made a new commit e, when you were pulling codes. Now, the situation becomes:
repo A： repoB：
d e
|\ |
b c c
|/ |
a a
OK. Now you have to pull the new commits to your repo again and make a new push request. And don't forget that there could be some new codes commited to the upstream... Theoretically you may have to loop forever.
And empiracally, you may finally make a well done push request with no conflication. Congratulations, but there are hundreds of push request. If the owner accept another push request first, you have to pull and push again.
Consequently, to make a contribution work neatly, the requested operation must have two parts:
- Eliminate conflictions.
- Combine branch.
And it must be done by the owner. Otherwise, the owner must:
- Approve a contributor's new code.
- Approve the contributor's way of eliminating confliction.
But just as the example, there may be some more conflictions introduced when the contributor is eliminating conflictions.
So, pull operation is naturally the choice. That's why there's pull request but no push request.
0
votes
I think its a silly terminology because I want to think that I want to PUSH something to you and not thinking vice versa asking someone else to pull mine addings. Therefore it should be changed into PUSH REQ. since I'm the active part. The arrow goes the other way starting with me and not the Goofy in the other end. IMHO.
0
votes
0
votes
A git pull means I am pulling from the repository.
A git push means I am pushing to the repository.
A pull request would naturally follow that I am asking the repo owner that I can pull from their repository, right?
Wrong, a pull request means I am requesting to (essentially) push to a repository.
The supposed logic behind this is that the repository is now the owner of the command essentially. But if this is the case then it would follow that retrieving code from a repository would be enacted by a git push. Because if the repository is the owner then they are solely responsible for pushing the code out to you. But no. Inconsistency is key.
The accepted answer states that "pushing" makes it sound like you are forcing the changes upon the repository, but that makes zero sense because you lose sight that it is a REQUEST. A request, by its very nature, is NOT forced upon anything.
git push. To me that says it all... (yes, they may issue git pull, then git push, but the push was asked for and is what is ultimately getting done) – ebyrobmerge requests. Much clearer, IMHO. :) – U007D