Por que uma solicitação pull não é chamada de solicitação push do git?


450

A terminologia usada para mesclar uma ramificação com um repositório oficial é uma 'solicitação pull'. Isso é confuso, pois parece que estou solicitando enviar minhas alterações para o repositório oficial.

Por que isso é chamado de solicitação pull e não push?


45
Imagine uma árvore grande e viva. A árvore é muito resistente para você empurrar um galho para dentro, em vez disso, você deve pedir à árvore para puxá-lo para dentro do tronco, fortalecendo-o.
Lucas


2
Se estiver usando um repositório remoto como o gitihub, é um dos últimos comandos que o mantenedor executará para atender à solicitação via linha de comando git push. Para mim, isso diz tudo ... (sim, eles podem emitir git pull, empurre então git, mas o impulso foi solicitado e é o que é em última análise, sendo feito)
ebyrob

60
O GitLab os chama merge requests. Muito mais claro, IMHO. :)
U007D 23/11

Respostas:


377

Se você possui uma alteração de código no seu repositório e deseja movê-lo para um repositório de destino, então:

  • "Push" é você forçando as alterações presentes no repositório de destino ( git push).
  • "Pull" é o repositório de destino, que captura suas alterações para estar presente no local ( git pulldo outro repositório ).

Uma "solicitação pull" é você solicitando o repositório de destino para obter suas alterações.

Uma "solicitação de envio" seria o repositório de destino solicitando que você enviasse suas alterações.


21
isso também foi um problema para mim com a convenção de nomenclatura: D & u simplificou muito a compreensão. pensar nisso da mesma maneira que a moeda de compra / venda nos bancos funciona.
Nsuinteger

Eu acho que você precisa redefinir sua definição de "Pull", porque há confusão sobre "repositório de destino", "suas alterações". Talvez você queira dizer que "o seu repositório está mudando do repositório de destino"?
precisa saber é o seguinte

9
A idéia principal é que a terminologia "push" / "pull" seja usada para identificar a parte que finalmente decide se a transferência ocorre, e não a parte que cria as informações que estão sendo transferidas.
21817 Jess Riedel

3
Depende de quem você está solicitando; se for sua equipe, uma "solicitação por push" faz mais sentido; se o repositório remoto estiver absolutamente certo.
A77 25/09

2
Ao trabalhar com um servidor Git central privado em uma empresa, normalmente você poderá enviar uma nova ramificação para ela e solicitar uma revisão de código e mesclagem de seus colegas de trabalho. Portanto, "solicitação de recepção" para esse fluxo de trabalho não é tecnicamente correta, mas acabou sendo o termo escolhido por todos e pelos designers da GUI.
Sven

88

Ao enviar uma solicitação de recebimento, você está solicitando (solicitando) ao proprietário do repositório oficial que faça algumas alterações em seu próprio repositório. Daí "solicitação de recebimento".


2
mas o proprietário vai emitir uma mesclagem git depois de aprová-la
Jervie vitriolo

2
Um git pull é uma busca e mesclagem combinadas, portanto, pull já implica mesclagem.
Xiong Chiamiov

37

tl; dr, já que não tenho permissão para fazer um push, farei uma solicitação ao proprietário do repositório, para que ele decida puxar


Quem pode enviar código para um repositório?

Se alguém (possivelmente mau, sem instrução ou desconhecido) puder vir aqui e dizer aqui, enviei isso para o seu ramo mestre e estraguei todo o seu código HAHAHA! ?

Certamente você não quer que ele faça isso. Por padrão, uma rede de segurança é configurada para que ninguém possa acessar seu repositório. Você pode definir outras pessoas como colaborador e , em seguida, elas podem enviar por push. Você daria esse acesso a pessoas em quem confia.

Portanto, se você não é um colaborador e tenta enviar, receberá um erro indicando que não tem permissão.


Então, como outros desenvolvedores podem enviar para um repositório que não têm permissão para enviar?
Você não pode dar acesso a todos, mas você quer dar outros um ponto de saída / entrada para que eles possam fazer 'um pedido para o proprietário repo para puxar este código para o repo'. Simplificando, tornando o repositório acessível, eles podem bifurcá-lo ... fazer suas alterações em seu próprio garfo. Envie as alterações para o próprio garfo . Quando estiver em seu próprio repositório remoto:

Eles fazem uma solicitação pull de sua bifurcação e o proprietário do repositório upstream (para o qual você não pode enviar diretamente) decide se deseja ou não mesclar a solicitação pull.


Também uma pergunta semi-relacionada, recomendo a leitura O que exatamente acontece em um push git? Por que um push git não é considerado como uma mesclagem git?


4
para pessoas que não percebem que há uma diferença de permissão entre empurrar e puxar, essa resposta faz muito sentido.
Buddha

29

Pull Pedido: I Solicitar a você para puxar o meu.


7
Eu, como usuário, vejo isso da minha perspectiva, não deveria ser "Eu solicito enviar isso a você?" I >>> You - Você está mudando o ponto de referência duas vezes no mesmo contexto ... em vez deI >>>> You <<<< Mine
Marin

1
Essa resposta faz mais sentido.
shivams

Easy peezy squeezy lemon
Ivan Ivković

Peço-lhe para puxar o meu ..... de onde ??? Estou entendendo que isso seria de uma bifurcação do projeto original? ou de uma cópia local?
KansaiRobot

5

Quero levar algo ao repositório de outra pessoa.

Eu não tenho permissão para empurrar (ou puxar, para esse assunto).

O proprietário / colaboradores tem permissões. Eles podem puxar e empurrar. Eu não posso empurrar.

Portanto, peço que eles executem uma solicitação minha - o que indiretamente significa que estou solicitando que eles aceitem meu pedido.

Portanto, nenhum pedido de envio. Apenas para puxar. E para aceitação de um empurrão.

Portanto, uma solicitação 'pull'. E não um pedido "push".


4

É a palavra "Solicitação" que é fundamental nessas ações. Você também pode pensar nisso como dizendo "Eu tenho um pedido para você aceitar meu trabalho, você aceita?" - "Uma solicitação de recebimento".

É um pouco confuso no começo, mas faz sentido eventualmente.


1

Para entender isso melhor e lembrá-lo para sempre, você precisa imaginá-lo.

Imagine uma árvore grande e viva {como seu repositório}. A árvore é muito resistente para você inserir um galho ou adicionar uma nova peça {simboliza a criação de um novo galho ou você introduz o código nele}; em vez disso, você deve pedir à árvore para puxar um galho para o tronco ou ter o muda de você.

O termo "solicitações de recebimento" vem da natureza distribuída. Em vez de apenas inserir suas alterações no repositório (como faria com um repositório centralizado, por exemplo, com o Subversion), você está publicando suas alterações separadamente e solicitando ao mantenedor que faça as alterações. O mantenedor pode então examinar as alterações e fazer o referido puxão.

Então você basicamente "solicita" os caras com acesso de gravação ao repositório ao qual deseja contribuir, para "Retirar" do seu repositório.

As solicitações pull permitem que você conte aos outros sobre as alterações que você enviou para uma ramificação em um repositório no GitHub. Depois que uma solicitação de recebimento é aberta, você pode discutir e revisar as possíveis alterações com os colaboradores e adicionar confirmações de acompanhamento antes que suas alterações sejam mescladas na ramificação base. Explicação do Github


0

Eu acho que é uma terminologia bobo porque eu quero pensar que eu quero empurrar algo para você e não pensar vice-versa pedindo alguém para puxar meus addings. Portanto, ele deve ser alterado para PUSH REQ. desde que eu sou a parte ativa. A flecha vai para o outro lado, começando comigo e não o Pateta do outro lado. NA MINHA HUMILDE OPINIÃO.


0

Pense assim. Repositório local vs repositório remoto.

  • Quando você pressiona do local. ( git push) - em outras palavras, o repositório remoto está recebendo códigos de você (local).

Você está solicitando alguma coisa. Então, pergunte a si mesmo,

  • Deseja repositório remoto, retirando códigos de você? - Solicitar Pull.

Eu acho que é importante fazer a distinção de que você não pode fazer solicitações push. Se você pode enviar por push e não fazê-lo, não é um pedido, ele se fundirá com o mestre. Uma solicitação pull para um repositório git hub é você solicitando que seu código seja mesclado.
James

Eu apenas uso isso como um exemplo. Obviamente, o Github pode empurrar o código. mas vou editar minha resposta.
Jin Lim

0

Receio que a maioria dessas respostas atenda à pergunta O que significa 'solicitação de recebimento'? ou O que 'solicitação de envio' significa? em vez da pergunta do OP: por que é chamada de solicitação pull e não push?

Normalmente, esse tipo de substituição de pergunta é aceitável, mas, neste caso, é claro que o OP conhece as respostas para essas perguntas de substituição, portanto, respondê-las não é muito útil.

Somente as pessoas no GitHub que cunharam o termo sabem com certeza. No entanto, parece evidente que essa escolha terminológica reflete algo como o seguinte ponto de vista sobre o fenômeno de "mudanças que chegam de fora a um repositório": O mantenedor executa a ação (pull) .

No entanto, uma solicitação também é uma ação, e o executor dessa ação não é o mantenedor, mas o remetente (que realizou ainda mais ações, ou seja, trabalho). Assim, o termo 'solicitação de recebimento' cria confusão sobre quem é o agente . Por fim, a confusão surge devido à natureza recursiva de uma solicitação: uma solicitação é uma ação de um agente primário e uma solicitação de ação futura de um segundo agente.

A situação é bastante análoga às construções lingüísticas agora comuns, como "construímos nossa casa" (usada no lugar de "pagamos outra pessoa para construir nossa casa"), pois a responsabilidade pela ação primária é transferida do óbvio agente original para um agente secundário cumprindo um papel social gerencial.

Pode-se concluir com isso que a razão da escolha terminológica é a legitimação do ponto de vista de que o trabalho gerencial é um trabalho de primeira classe . Além disso, o motivo da confusão sobre essa escolha terminológica pode ser que os trabalhadores que não são gerentes naturalmente têm um ponto de vista diferente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.