Why is a git 'pull request' not called a 'push request'?

Question

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?

Claraclarabella

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. – Maracanda

Possible duplicate of Why does GitHub call foreign submissions, a "Pull Request"? – Eckenrode

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) – Humpback

GitLab calls them merge requests. Much clearer, IMHO. :) – Wax

duplicate:#14817551 – Icaria

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. – Unbalance

I like the answer that @Maracanda gave, it strengthens the idea that the master of all is the solid piece of software in the master branch. – Arlyn

@Maracanda 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. – Noll

Answer 1

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.

Roster

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. – Acanthaceous

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"? – Leora

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. – Carabin

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. – Tunnel

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. – Roster

Still would be better the other way around. I know no one who intuitively got it right. – Vincevincelette

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. – Koa

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. – Aldose

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!!" – Quianaquibble

In context of admin of git repository its pull request, because that admin user will merge that content by pulling into its master repository. – Toil

The entire concept confuses me. What a bunch of gits. Thanks for the explanation though. It is helpful. – Suprasegmental

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 – Mockheroic

@Sven, your terminology I think is wrong in ways that might confuse newbies. Your description of "pull" matches what Git calls fetch, and you don't mention the fact completing a pull request always involves a merge. And in fact: (1) the pull operation in Git is identical to fetch followed by merge; and (2) completing a pull request always involves a merge, but does not always involve a fetch (depending on whether the source branch is already in the target repo). – T

@KeithRussell In the answer am not going into any details of how to run git on the command line or somewhere else. I rely on the fact that people may run git pull, knowing what that would do. And diverting into details about fetch/merge vs. pull would affect the clarity to explain why it is called a pull request. It isn't exactly called "fetch and merge" request for a reason. – Roster

Answer 2

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".

Incomplete

but the owner will issue a git merge after approving it – Carlile

A git pull is a fetch and merge combined, so pull already implies merge. – Fer

Answer 3

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?

Me

for people that don't realize that there is a permission difference between push and pull, this answer makes a lot of sense. – Tiu

Answer 4

Pull Request: I Request to you to Pull mine.

Summary

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 – Jacklyn

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? – Racism

@Racism From local copy or your working directory. – Summary

Answer 5

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.

Encratia

Answer 6

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.

Dovelike

Answer 7

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.

Erase

Answer 8

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

Dimitri

Answer 9

It depends from which angle you see this.

If you try merging branch B to A, you are probably observing it from B branch side (the changes that you have pushed) and call it push.

But, git looks at it from A side (the base code). Git needs to checkout to A first. Then, it applies changes of B to A which is pulling B to A.

Retire

Answer 10

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.

Brothers

Answer 11

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

Darya

Answer 12

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.

Aquila

Answer 13

The answer here is simple and buried in the annals of Git history.

Git was created by Linus (of Linux fame) because of all the drama around their coding version control systems wrt the licensing, costs, etc.

So in Linus fashion he disappeared for a time into the wilderness and hacked his own SVC: Git.

When the Linux community started using Git all the organising of Linux etc was done by direct email and on mailing lists.

So a Pull Request was literally an email sent to Linus (or someone else who you wanted feedback from wished to to merge your code with) requesting they pull from your Git branch/fork. Hence the name Pull Request.

Here's a link to one of the mailing lists where they started formalising how these emails would look and be formatted:

https://lore.kernel.org/all/[email protected]/

Daune

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Appoint

Answer 14

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.

Orcein

Answer 15

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.

Instate

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. – Voroshilov

I just use this as an example. Of course, Github can push the code. but I will edit my answer. – Instate

Answer 16

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.

Mongol

Although this is completely reasonable, it's the reason it shouldn't be called a pull request, not the reason that it is. – Sf

Answer 17

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.

Delozier

Answer 18

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.

Stockman

Answer 19

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.

Suiter

Answer 20

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.

Baseler

Answer 21

It is called pull request and not push request because

Note: pull consists of git fetch followed by git merge or git rebase.

1. push, pull and pull request are defined/seen from the perspective of the one that executes them.
2. When you are not allowed to push to the original repo but still want your changes end up in there, your next option is to make a plea to the original repo admins so that they would pull in your changes. That plea is a pull request.

The workflow is

1. You execute a push - move your changes to your repository.
2. You execute a pull request to the official repository admins, for them to pull in your changes from your repo.
3. The official repo admins execute pull¹ on your changes, adding them into the official repo from your repo.

Merge request is a more intuitive name for pull request

...since the push/pull direction technicality does not have to be considered when using the merge request terminology.

Gitlab uses the term merge request instead of pull request. Probably because merge is both a git command and intuitive, I guess.

Integrate request or reconcile request would be even better terms

Your main goal is to get your changes into the original repo, no matter how the original repo admin does it - by merging or rebasing.

Since the original repo admin can either choose to do a git merge or git rebase, the term merge request is not ideal either.

Integrate request or reconcile request would be even more intuitive and also more technically correct, since these would also leave open the rebase way of adding your changes, not confining the term to the merge way. Otherwise someone might get confused wanting to do a rebase request instead of a merge request, thinking that merge request won't allow to do a rebase request.

The words integrate and reconcile are chosen here partially because they are used in the description of git pull in the extensive source of git info, https://git-scm.com/docs/git-pull

NB! There are NO commands in git called integrate request nor reconcile request as of today. Maybe in a future, if someone with decisive power agrees to this idea.

---

¹ In theory. In practice there are gh pr in GitHub and merge_request in GitLab.

Hunchbacked