725

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?

Amal K
  • 4,359
  • 2
  • 22
  • 44
Alejandro Sanz Díaz
  • 7,842
  • 4
  • 17
  • 23
  • 101
    Picture a big, living tree. The tree is too sturdy for you to push a branch into in, instead you must ask the tree to pull a branch into the trunk, strengthening it. – Luke Jun 13 '16 at 20:54
  • 9
    Possible duplicate of [Why does GitHub call foreign submissions, a "Pull Request"?](http://stackoverflow.com/questions/14817051/why-does-github-call-foreign-submissions-a-pull-request) – Cosmos Gu Aug 30 '16 at 04:53
  • 4
    If using a remote repository like gitihub, one of the last commands the maintainer will execute in fulfilling the request via command line is `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) – ebyrob Sep 30 '16 at 14:19
  • 131
    GitLab calls them `merge requests`. Much clearer, IMHO. :) – U007D Nov 23 '16 at 22:00
  • 1
    duplicate:https://stackoverflow.com/questions/14817051/why-does-github-call-foreign-submissions-a-pull-request – Timothy Swan Sep 29 '17 at 15:55
  • 26
    The real question is "why didn't they call it a 'merge request'" so you did not have to have the perspective of the repo owner. Poor design. – Cerniuk Oct 23 '19 at 12:04
  • I like the answer that @Luke gave, it strengthens the idea that the master of all is the solid piece of software in the master branch. – James Hatton Nov 02 '21 at 09:15
  • @Luke While the analogy is helpful, the naming is still inconsistent. When you do a pull request, you ask that the the repo pull your changes, but when you do a push request you ask that *you* push the changes. – Mehdi Charife Jun 22 '23 at 13:28

18 Answers18

617

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 pull from 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.

Sven
  • 69,403
  • 10
  • 107
  • 109
  • 39
    this has been a problem for me also with the naming convention :D & u just made it much simpler to understand. to think of it its the same way how the currency buy/sell in banks work. – nsuinteger Apr 16 '14 at 14:34
  • I think you need redefine your definition of "Pull", because there is confusing about "target repository", "your changes". Maybe you want to say, that "your repository grabbing changes from target repository"? – MrPisarik Jun 02 '16 at 06:44
  • 20
    The key idea is that the "push"/"pull" terminology is used to identify the party who ultimately decides whether the transfer happens, *not* the party who creates the information being transferred. – Jess Riedel Jul 25 '17 at 16:16
  • 7
    It depends on **who** are you requesting, if it is your team a "push request" makes more sense, if it is the remote repository your absolutely right. – A77 Sep 25 '17 at 10:57
  • 4
    When working with a central, private Git server in a company, usually you'd be able to push a new branch to it, and request a code review and merge from your co-workers. So "pull request" for this workflow isn't technically correct, but it turned out to be the term chosen by everyone and the GUI designers. – Sven Sep 29 '17 at 13:59
  • 2
    Still would be better the other way around. I know no one who intuitively got it right. – user2762996 Oct 09 '17 at 17:05
  • 1
    despite this meaningful answer, I am still uncomfortable with this pull request term. I am asking the master branch to allow me to push my changes into it. it is a push request. – schlingel Oct 01 '18 at 11:09
  • So after I do a pull request, I'm done, right? Because the repo owner will then pull my changes onto the master branch. Is that correct? Some tutorials claim that after we have done git add and git commit we then must do git pull then git push. It's very confusing. – David Spector Jan 14 '19 at 02:28
  • 3
    Intuitively speaking, `push` = "Hey I'm going to push this and I don't care what you think". `pull request` = "Could you pull this, if you think it's okay? I'm requesting it!!" – Leonard Mar 18 '20 at 05:22
  • In context of admin of git repository its pull request, because that admin user will merge that content by pulling into its master repository. – Akash Pagar May 28 '20 at 13:55
  • 1
    The entire concept confuses me. What a bunch of gits. Thanks for the explanation though. It is helpful. – Neo42 Feb 23 '23 at 12:56
  • It doesn't make sense. But we're going to keep calling it a Pull Request unless you personally want to tell all your SWE friends to start calling it a Merge Request or Push Request *shrug* – Nathan majicvr.com Jul 03 '23 at 18:46
133

When you send a pull request, you're asking (requesting) the official repo owner to pull some changes from your own repo. Hence "pull request".

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
61

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 (usually) 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:

  1. review your branch
  2. give you approvals
  3. fetch your branch
  4. merge it with master

(3+4 = git pull)


As an aside, you might ask, why isn't it named as 'merge request'?!

The best answer I found for that is, if you're just making commits directly to main — without ever having multiple feature branches, then you don't ever have merge (two parents forming a child) commits. All commits are just new commits to the previous. Hence the name 'merge commit' won't apply.


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?

mfaani
  • 33,269
  • 19
  • 164
  • 293
  • 10
    for people that don't realize that there is a permission difference between push and pull, this answer makes a lot of sense. – buddie Oct 31 '17 at 08:31
42

Pull Request: I Request to you to Pull mine.

hepidad
  • 1,698
  • 1
  • 15
  • 16
  • 10
    I as a user view it from my perspective, shouldn't it be " I request to push it to you ?" `I >>> You` - You're changing the point of reference twice in the same context... rathern than `I >>>> You <<<< Mine` – Marin Nov 21 '16 at 02:58
  • I request to you to pull mine..... from where??? I am understanding this would be from a fork of the original project? or from a local copy? – KansaiRobot May 04 '20 at 02:27
  • @KansaiRobot From local copy or your working directory. – hepidad Oct 23 '20 at 04:52
10

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.

user11705414
  • 101
  • 1
  • 2
10

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.

jimmymathews
  • 139
  • 1
  • 6
4

It's the word "Request" that is key in these actions. You could also think of it as saying "I have a request for you to take my work, do you accept?" - "A Pull Request".

It's slightly confusing at first, but makes sense eventually.

Kyzer
  • 518
  • 5
  • 9
4

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

Sunil Garg
  • 484
  • 5
  • 9
1

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 push and fail. Because A and B conflict.
  • You git push --force and success. However, commit c is gone. It becomes
repo A:  repoB:
  b        b
  |        |
  a        a

This is not 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.

SleepyBag
  • 103
  • 1
  • 6
1

A pull request is generating a request asking the repo to pull your changes.

user1154422
  • 548
  • 8
  • 22
1

I think one must look it regarding the collaborative development model they are using.

When you are working in a fork and push model, Where only a maintainer is allowed to approve your changes and pull them in the main branch. You can call it a pull request.

But what if you are working in a shared repository model in which you might actually be the one pushing your changes after getting approval from others to the main branch. Then IMHO you are allowed to think of it as a push request.

So, Although it might not seem wrong to see it as a push request, most of the time it seems to be a pull request. Maybe they preferred not to use 2 different terms for the two close concepts or maybe they just name the pull request in the fork and push model and did not care about the other.

However I agree with U007D'comment where he said the alternate name of merge request is more suitable for both concepts.

e1985t
  • 21
  • 2
0

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.

Michael Pauli
  • 51
  • 1
  • 6
0

Think This way. Local repository vs Remote repository.

  • When you Push from Local. (git push) - in other words, the Remote repository is Pulling codes from you(Local).

You are requesting something. So, ask your self,

  • Do you want Remote repository Pulling codes from you? - Pull Request.
Jin Lim
  • 1,759
  • 20
  • 24
  • I think it's important to make the distinction that you can't make push requests. If you can **push** and you do so, it isn't a request, it'll merge with the master. A pull request towards a git hub repository is you requesting that your code be merged. – James Dec 13 '19 at 15:57
  • I just use this as an example. Of course, Github can push the code. but I will edit my answer. – Jin Lim Dec 14 '19 at 18:13
0

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.

Ryan M
  • 18,333
  • 31
  • 67
  • 74
Ying n Yang
  • 79
  • 1
  • 3
  • Although this is completely reasonable, it's the reason it *shouldn't* be called a pull request, not the reason that it *is*. – DCShannon Sep 07 '22 at 15:31
0

Think from sitting in the shoes of the repo side !! Pull request - This means, Git will say to the repo, that you have something outside to get in, so from the repo point of view it's a pull, So it's a pull request.

ferraro
  • 322
  • 2
  • 13
0

Any terminology that needs a paragraph of explanation goes to show that the terminology is not intuitive and has complications or one-sidedness behind its choice. There are a lot of well written explanations above so I won't add further to it but here is my commentary on my frustration with the terms push and pull in git.

Consider normal labels of Push and Pull on a door.

Its interpreted from the eyes of the person who is about to operate the door.

If it says Push, the person will "push".

If it says Pull, naturally , there is a knob that will be used to pull the door towards oneself.

Now imagine if gitHub manufactured doors and wrote "Pull" on a door simply to be pulled from the other end and not your end ( so in a way its Push in normal world!). You would then engage your mind to counter-act the intuitive thinking and translate the door pull to a door push.

It is that sort of thinking that is leading to this confusion.

The system 1 of our brain which relies on intuitive , primary interpretations would enter a conflict zone.

I have simply chosen to accept this anomalous definition of git Pull and Push requests and remember it as one of the many exceptions once comes to terms with in life and move on.

0

Simply, because you request to Pull (get a copy) the code, but in Push you request to integrate your code by pushing it into the target.

Deema A.
  • 1
  • 1
0

It’s something of a surprise to me no one has stumbled on the correct answer in the nine years since this was first asked.

Being historical in nature, the question can only be answered by historical sources. Zach Holman has disclosed that pull request was so named at GitHub because it was initially based on git request-pull.