De ce nu se numește o „pull request” git „push request”? (Programare, Git, Github, Cerere De Tragere)

Alejandro Sanz Díaz a intrebat.

Terminologia utilizată pentru a unifica o ramură cu un depozit oficial este „pull request”. Acest lucru este derutant, deoarece se pare că eu solicit să împing modificările mele în depozitul oficial.

De ce se numește „pull request” și nu „push request”?

Comentarii

    59

  • Imaginați-vă un copac mare și viu. Copacul este prea robust pentru ca tu să împingi o ramură în el, în schimb trebuie să îi ceri copacului să tragă o ramură în trunchi, întărindu-l. –  > Por Luca.
  • Possible duplicate of De ce GitHub numește trimiterile străine, o „Pull Request”? –  > Por Cosmos Gu.
  • Dacă se folosește un depozit la distanță, cum ar fi gitihub, una dintre ultimele comenzi pe care le va executa mentorul în îndeplinirea cererii prin linia de comandă este git push. Pentru mine, asta spune totul… (da, s-ar putea să emită git pull, apoi git push, dar push-ul a fost cerut și este ceea ce se face în cele din urmă) – –  > Por ebyrob.
  • 70

  • GitLab le numește merge requests. Mult mai clar, IMHO. 🙂 –  > Por U007D.
  • Adevărata întrebare este „de ce nu au numit-o „cerere de fuziune””, astfel încât să nu trebuiască să aveți perspectiva proprietarului repo-ului. Proiectare slabă. –  > Por Cerniuk.
12 răspunsuri
Sven

Dacă aveți o modificare de cod în depozitul dvs. și doriți să o mutați într-un depozit țintă, atunci:

  • „Push” înseamnă că forțezi modificările să fie prezente în depozitul țintă (git push).
  • „Pull” înseamnă că depozitul țintă îți preia modificările pentru a fi prezente acolo (git pull din celălalt repo).

O „cerere de extragere” înseamnă că solicitați depozitarului țintă să preia modificările dumneavoastră.

O „solicitare de împingere” ar însemna ca depozitul țintă să vă solicite să vă împingeți modificările.

Comentarii

    27

  • aceasta a fost o problemă și pentru mine cu convenția de denumire :Damp; tocmai ai făcut-o mult mai simplu de înțeles. dacă mă gândesc la ea, este la fel cum funcționează cumpărarea/vânzarea de valută în bănci. –  > Por nsuinteger.
  • Cred că trebuie să redefiniți definiția de „Pull”, pentru că există o confuzie în ceea ce privește „depozitul țintă”, „modificările tale”. Poate că doriți să spuneți că „depozitul dumneavoastră preia modificările din depozitul țintă”? –  > Por MrPisarik.
  • Ideea cheie este că terminologia „push”/”pull” este utilizată pentru a identifica partea care decide în cele din urmă dacă se realizează transferul, nu partea care creează informațiile care sunt transferate. –  > Por Jess Riedel.
  • Depinde de cine solicitați, dacă este vorba de echipa dvs., o „cerere push” are mai mult sens, dacă este vorba de depozitul la distanță, aveți perfectă dreptate. –  > Por A77.
  • Atunci când lucrați cu un server Git central, privat, într-o companie, de obicei, puteți să trimiteți o nouă ramură către acesta și să solicitați o revizuire a codului și o fuziune din partea colegilor dumneavoastră. Așadar, „pull request” pentru acest flux de lucru nu este corect din punct de vedere tehnic, dar s-a dovedit a fi termenul ales de toată lumea și de designerii GUI. –  > Por Sven.
JB Nizet

Atunci când trimiteți o cerere de extragere, îi cereți (solicitați) proprietarului oficial al repo-ului să extragă unele modificări din propriul repo. De aici și „pull request”.

Comentarii

  • dar proprietarul va emite o fuziune git după ce o aprobă –  > Por Jervie Vitriolo.
  • Un git pull este un fetch și un merge combinat, deci pull implică deja merge. –  > Por Xiong Chiamiov.
Miere

tl;dr din moment ce nu mi se permite să fac un push, voi face o cerere drăguță proprietarului repo-ului pentru ca acesta să decidă să facă un pull


Cine poate să împingă cod într-un depozit?

Ar trebui ca oricine (eventual malefic sau needucat sau necunoscut) să poată veni și să spună iată, tocmai am împins asta în ramura ta principală și ți-am stricat tot codul HAHAHA! ?

Cu siguranță nu vreți ca el să facă asta. În mod implicit, o plasă de siguranță este setată astfel încât nimeni nu poate face push la repo-ul tău. Tu puteți setați alte persoane ca și colaborator, apoi pot face push. Ați acorda un astfel de acces persoanelor în care aveți încredere.

Astfel, dacă nu sunteți colaborator și încercați să faceți push, veți primi o eroare care indică faptul că nu aveți permisiunea.


Așadar, cum pot alți dezvoltatori să facă push către un repo pentru care nu au permisiunea de a face push?
Nu puteți oferi acces tuturor, dar doriți să dați acces la toată lumea. altora un punct de intrare/ieșire pentru ca ei să poată face „o cerere către proprietarul repo-ului pentru a să tragă acest cod în repo”. Pur și simplu, făcând repo-ul accesibil, ei pot să îl bifurce… să își facă modificările în propriul lor fork. Push modificările lor către propriul lor fork. Odată ce sunt în propriul lor repo la distanță:

Ei fac un cerere de tragere din furculița lor, iar proprietarul repo-ului din amonte (în care nu puteți face push direct) va decide dacă va fuziona sau nu cererea de pull request.


Pentru a explica dintr-un alt unghi:

pushing este pentru lucruri pe care le nu aveți nevoie de aprobarea nimănui, de exemplu, puteți oricând să faceți push către o ramură a unei caracteristici pe care ați creat-o dumneavoastră și la care ați făcut commit.

În timp ce puteți crea o cerere de tragere între două ramuri pe care le-ați creat și pe care le puteți împinge. Aproape niciodată nu faceți asta.

Am făcut acest lucru atunci când lucram la o caracteristică mare și aveam deja aprobări pentru cererea mea, dar aveam nevoie să fac o schimbare dificilă, așa că am creat un PR pentru ramura mea existentă.

Dacă apoi aveți nevoie de aprobare, atunci nu doriți să faceți push. Vrei ca alții să o facă:

  1. să vă revizuiască ramura
  2. să vă dea aprobări3a. să vă aducă ramura3b. să o îmbine cu cea principală

(3a+3b = git pull)


De asemenea, o întrebare semi-relaționată vă recomand să citiți Ce se întâmplă exact într-un git push? De ce un git push nu este considerat la fel ca un git merge?

Comentarii

  • pentru persoanele care nu realizează că există o diferență de permisiune între push și pull, acest răspuns are mult sens. –  > Por buddie.
hepidad

Pull Request: I Cerere să vă Pull mea.

Comentarii

  • Eu, în calitate de utilizator, o privesc din perspectiva mea, nu ar trebui să fie „Îți cer să ți-l împing?”? I >>> You – Schimbați punctul de referință de două ori în același context… mai degrabă decât I >>>> You <<<< Mine –  > Por Marin.
  • Acest răspuns are cel mai mult sens. –  > Por shivams.
  • Easy peezy lemon squeezy –  > Por Ivan Ivković.
  • Vă rog să scoateți mine….. de unde????? Înțeleg că ar fi de la o bifurcație a proiectului original? sau de la o copie locală? –  > Por KansaiRobot.
  • @KansaiRobot Din copia locală sau din directorul tău de lucru. –  > Por hepidad.
user11705414

Vreau să împing ceva în repo-ul altcuiva.

Nu am permisiunea de a face push (sau pull, de altfel).

Proprietarul/colaboratorii au permisiuni. Ei pot face pull, precum și push. Eu nu pot face push.

Așadar, le cer să efectueze un pull de la mine – ceea ce înseamnă, indirect, că le cer să accepte push-ul meu.

Așadar, nu există nicio cerere de push. Doar pentru un pull. Și pentru acceptarea unei împingeri.

Prin urmare, o cerere de „tragere”. Și nu o cerere de „împingere”.

Kyzer

Cuvântul „Request” este cheia în aceste acțiuni. Te-ai putea gândi, de asemenea, că ar fi ca și cum ai spune: „Am o solicitare pentru ca tu să-mi iei munca, accepți?”. – „O cerere de tip „Pull Request”.

Este ușor confuz la început, dar în cele din urmă capătă sens.

jimmymymathews

Mi-e teamă că majoritatea acestor răspunsuri se adresează întrebării Ce înseamnă „pull request”? sau Ce ar însemna ‘push request’? mai degrabă decât la întrebarea lui OP: De ce se numește „pull request” și nu „push request”?

În mod normal, acest tip de înlocuire a întrebărilor este acceptabil, dar în acest caz este clar că OP cunoaște răspunsurile la aceste întrebări de înlocuire, așa că răspunsul la ele nu este foarte util.

Doar cei de la GitHub care au inventat termenul știu sigur. Cu toate acestea, pare evident că această alegere terminologică reflectă ceva de genul următorului punct de vedere cu privire la fenomenul „modificărilor care intră într-un depozit din exterior”: Responsabilul de întreținere face acțiunea (pull).

Cu toate acestea, o cerere este, de asemenea, o acțiune, iar cel care o face nu este responsabilul cu întreținerea, ci mai degrabă cel care o depune (care a făcut și mai multă acțiune, și anume muncă). Astfel, termenul „pull request creează confuzie cu privire la cine este agentul. În cele din urmă, confuzia apare din cauza naturii recursive a unei cereri: O cerere este atât o acțiune a unui agent primar, cât și o cerere pentru o acțiune viitoare a unui al doilea agent.

Situația este destul de analogă cu construcțiile lingvistice comune în prezent, cum ar fi „ne-am construit casa” (folosită în loc de „am plătit pe altcineva să ne construiască casa”), în sensul că responsabilitatea pentru acțiunea primară este transferată de la agentul original evident la un agent secundar care îndeplinește un rol social managerial.

S-ar putea concluziona de aici că motivul alegerii terminologice este legitimarea punctului de vedere conform căruia munca managerială este o muncă de primă clasă. În plus, motivul pentru care confuzie cu privire la această alegere terminologică poate fi faptul că lucrătorii care nu sunt manageri au, în mod natural, un punct de vedere diferit.

SPidey

Pentru a înțelege mai bine acest lucru și pentru a-l reține pentru totdeauna, trebuie să vi-l imaginați.

Imaginați-vă un copac mare și viu {ca depozit}. Arborele este prea robust pentru ca tu să împingi o ramură în el sau să adaugi o nouă parte în el {simbolizează crearea unei noi ramuri sau faptul că tu împingi cod în el}, în schimb trebuie să ceri arborelui să tragă o ramură în trunchi sau să primească modificările de la tine.

Termenul „pull requests” provine din natura distribuită. În loc să vă împingeți pur și simplu modificările în depozit (așa cum ați face cu un depozit centralizat, de exemplu, cu Subversion), vă publicați modificările separat și cereți administratorului să vă tragă modificările în depozit. Responsabilul poate apoi să se uite peste modificări și să facă respectiva extragere.

Deci, practic, le „cereți” celor care au acces de scriere la repo-ul la care doriți să contribuiți să „tragă” din repo-ul dumneavoastră.

Cererile de tip „Pull” vă permit să le spuneți celorlalți despre modificările pe care le-ați introdus într-o ramură a unui depozit de pe GitHub. Odată ce o cerere de tragere este deschisă, puteți discuta și revizui potențialele modificări cu colaboratorii și puteți adăuga comisioane de urmărire înainte ca modificările dvs. să fie îmbinate în ramura de bază.Explicația Github

SleepyBag

Nu este vorba doar de subiectiv și obiectiv. De asemenea, este logic să spui „cer să împing” dacă în spate se află de fapt o operațiune de împingere.

Motivul principal este acela că nu se poate push la repo-ul altora. În schimb, trebuie să le solicitați să pull ramura ta.

Așadar, de ce GitHub nu vă permite să solicitați să push? În mod intuitiv, acest tip de abordare are sens și dacă managerii pot alege să accepte sau să refuze cererea mea de push, la fel cum aleg să accepte sau să refuze to pull repo-ul meu.


Să ne uităm la push întâi. Să spunem că există două repo, A și B:

repo A:  repoB:
  b        c
  |        |
  a        a

A și B au comiterea b și c pe comiterea a, respectiv.

În acest caz push de la A la B. Există două tipuri de rezultate.

  • Tu git push și eșuează. Pentru că A și B intră în conflict.
  • Tu git push --force și succesul. Cu toate acestea, angajamentul c a dispărut. Ea devine
repo A:  repoB:
  b        b
  |        |
  a        a

Asta e ceea ce vrei să faci, nu-i așa? Așa că trebuie să o faci altfel.


Trebuie să eliminați confuziile înainte de a push. De exemplu, trebuie să pull mai întâi repo-ul din amonte și să obțineți

repo A:  repoB:
  d
  |
  b c      c
  |/       |
  a        a

Și apoi puteți să push.

Acesta este modul în care un solicitare push arată astfel: contribuitorii se ocupă mai întâi de conflicte și solicită să facă o push operațiune de modificare a repo-ului din amonte. Poate că acum pare îngrijit. Managerul repo-ului din amonte poate alege să accepte sau să refuze cererea de push a contribuitorilor. Totul funcționează.


Cu toate acestea, funcționează doar dacă nu există nicio altă cerere push.

Să zicem că tocmai ați făcut o cerere de push după ce ați extras ramura din amonte și ați rezolvat conflictele. Credeți că ați terminat, dar nu, de fapt, nu. Aflați cu surprindere că proprietarul repo-ului din amonte tocmai a făcut un nou commit e, în momentul în care trăgeați codurile. Acum, situația devine:

repo A:  repoB:
  d        e
  |       |
  b c      c
  |/       |
  a        a

OK. Acum trebuie să pull noile comenzi în repo-ul tău din nou și să faci o nouă cerere de push. Și nu uitați că ar putea exista noi coduri comisionate în upstream… Teoretic, este posibil să trebuiască să faci o buclă la nesfârșit.

Și, în mod empiric, s-ar putea ca, în cele din urmă, să faceți o cerere de push bine făcută, fără nicio confuzie. Felicitări, dar există sute de cereri de tip push request. Dacă proprietarul acceptă mai întâi o altă cerere push, va trebui să pull și push din nou.


În consecință, pentru ca o contribuție să funcționeze în mod ordonat, operațiunea solicitată trebuie să aibă două părți:

  • Eliminați conflictele.
  • Combină ramura.

Și trebuie să fie făcută de către proprietar. În caz contrar, proprietarul trebuie:

  • Să aprobe noul cod al unui contributor.
  • Să aprobe modul în care contribuabilul elimină conflictele.

Dar, la fel ca în exemplu, este posibil să mai apară unele conflicte introduse atunci când colaboratorul elimină conflicte.

Deci, pull operațiunea este, în mod natural, alegerea. De aceea există pull cerere, dar nu există push cerere.

Michael Pauli

Cred că este o terminologie prostească, pentru că vreau să cred că I vreau să vă împing ceva și nu să mă gândesc viceversa, cerând altcuiva să îmi scoată adaosurile. Prin urmare, ar trebui să fie schimbată în PUSH REQ. deoarece eu sunt partea activă. Săgeata merge în sens invers începând cu mine și nu cu Goofy în celălalt capăt. IMHO.

Jin Lim

Gândiți în acest fel. Depozit local vs Depozitul la distanță.

  • Atunci când Împingeți de la local. (git push) – cu alte cuvinte, depozitul la distanță este Pulling coduri de la dumneavoastră (local).

Dumneavoastră solicitați ceva. Așadar, întrebați-vă,

  • Doriți un depozit de la distanță Extragerea coduri de la tine? – Cerere de extragere.

Comentarii

  • Cred că este important să se facă distincția că nu puteți face cereri de tip push. Dacă puteți push și faceți acest lucru, nu este o cerere, ci se va îmbina cu masterul. O solicitare de tip pull request către un depozit git hub înseamnă că tu ceri ca codul tău să fie fuzionat. –  > Por James.
  • Folosesc acest lucru doar ca exemplu. Bineînțeles, Github poate împinge codul. dar îmi voi edita răspunsul. –  > Por Jin Lim.
Ying n Yang

Un git pull înseamnă că extrag din depozit.

Un git push înseamnă că împing în depozit.

O cerere de extragere ar trebui să însemne în mod natural că îi cer proprietarului depozitului să pot extrage din depozitul său, nu?

Greșit, o solicitare de tip pull înseamnă că solicit (în esență) un push către un depozit.

Presupusa logică din spatele acestui lucru este că depozitul este acum proprietarul comenzii, în esență. Dar, dacă acesta este cazul, atunci ar trebui să rezulte că recuperarea codului dintr-un depozit ar trebui să fie promulgată printr-o comandă git push. Pentru că, dacă depozitul este proprietarul, atunci el este singurul responsabil pentru trimiterea codului către dumneavoastră. Dar nu. Inconsecvența este cheia.

Răspunsul acceptat afirmă că „împingerea” face să pară că forțezi modificările asupra depozitului, dar acest lucru nu are niciun sens, deoarece nu mai ai în vedere faptul că este vorba de o CERERE. O cerere, prin însăși natura sa, NU este forțată asupra a ceva.