Warum wird eine Git-"Pull-Anfrage" nicht als "Push-Anfrage" bezeichnet?

Question

Die Terminologie, die verwendet wird, um einen Branch mit einem offiziellen Repository zusammenzuführen, ist ein 'Pull-Request'. Das ist verwirrend, da es so aussieht, als würde ich darum bitten, meine Änderungen in das offizielle Repository zu übertragen.

Warum wird es als ein Pull-Request bezeichnet und nicht als ein Push-Request?

Answer 1

Ich möchte etwas in das Repo von jemand anderem pushen.

Ich habe nicht die Berechtigung zum Pushen (oder auch zum Pullen).

Der Besitzer/Kollaborateure hat Berechtigungen. Sie können sowohl pullen als auch pushen. Ich kann nicht pushen.

Daher bitte ich sie, einen Pull von mir durchzuführen - was indirekt bedeutet, dass ich sie bitte, meinen Push zu akzeptieren.

Also, keine Anfrage zum Pushen. Nur zum Pullen. Und zur Akzeptanz eines Pushes.

Deshalb eine 'pull' Anfrage. Und keine 'push' Anfrage.

Answer 2

Um dies besser zu verstehen und es für immer zu behalten, musst du es dir vorstellen.

Stell dir einen großen, lebendigen Baum {als deinen Speicher} vor. Der Baum ist zu robust für dich, um einen Ast hineinzudrücken oder einen neuen Teil hinzuzufügen {symbolisiert das Erstellen eines neuen Astes oder das Einfügen von Code}, stattdessen musst du den Baum bitten, einen Ast in den Stamm zu ziehen oder Änderungen von dir zu erhalten.

Der Begriff "Pull Requests" stammt aus der verteilten Natur. Anstatt einfach deine Änderungen in den Speicher zu drücken (wie du es mit einem zentralisierten Speicher tun würdest, z.B. mit Subversion), veröffentlichst du deine Änderungen separat und bittest den Verwalter, deine Änderungen einzuziehen. Der Verwalter kann dann die Änderungen überprüfen und den genannten Einzug vornehmen.

Also "forderst" du im Grunde die Leute mit Schreibzugriff auf den Speicher, zu dem du beitragen möchtest, auf, von deinem Speicher "einzuziehen".

Pull-Requests ermöglichen es dir, anderen von den Änderungen zu berichten, die du an einem Ast in einem Speicher auf GitHub gepusht hast. Sobald ein Pull-Request geöffnet ist, kannst du die potenziellen Änderungen mit Mitarbeitern diskutieren und überprüfen und Nachfolge-Commits hinzufügen, bevor deine Änderungen in den Basistest einfließen. Github Erklärung

Answer 3

Das Wort "Anfrage" ist der Schlüssel bei diesen Aktionen. Man könnte auch daran denken, dass es heißt "Ich habe eine Anfrage an dich, meine Arbeit zu übernehmen, akzeptierst du das?" - "Ein Pull Request".

Am Anfang ist es etwas verwirrend, aber irgendwann ergibt es Sinn.

Answer 4

Es geht nicht nur um subjektive und objektive. Es ist auch logisch zu sagen "Ich bitte um das Drücken", wenn tatsächlich dahinter eine Drückoperation liegt.

Der Hauptgrund dafür ist, dass du nicht in das Repo anderer Leute pushen kannst. Stattdessen musst du sie bitten, deinen Branch zu pullen.

Warum erlaubt GitHub also nicht, um das pushen zu bitten? Intuitiv macht dieser Ansatz auch Sinn, wenn die Manager in der Lage sind, meine push genauso zu akzeptieren oder abzulehnen, wie sie meine Repobitte pullen können.

---

Lass uns zuerst auf das pushen schauen. Sagen wir, es gibt zwei Repos, A und B:

repo A  repoB
  b        c
  |        |
  a        a

A und B haben Commit b bzw. c auf Commit a.

Dann pushst du von A nach B. Es gibt zwei Arten von Ergebnissen.

• Du git pushst und scheiterst. Weil A und B konflikten.

• Du git pushst --force und es gelingt. Allerdings ist Commit c weg. Es wird zu

  repo A repoB b b | | a a

Das ist nicht das, was du tun möchtest, richtig? Du musst es also anders machen.

---

Du musst die Konflikte vor einem pushen beseitigen. Sagen wir, du musst zuerst das Upstream-Repo pullen und erhältst

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

Und dann kannst du pushen.

So sieht ein Push-Anforderungs-System aus: Mitwirkende lösen zuerst die Konflikte und bitten dann um eine push-Operation, um das Upstream-Repo zu ändern. Vielleicht sieht es jetzt ordentlich aus. Der Manager des Upstream-Repo kann wählen, die Push-Anfrage der Mitwirkenden zu akzeptieren oder abzulehnen. Alles funktioniert.

---

Allerdings funktioniert es nur , wenn es keine andere Push-Anforderung gibt.

Angenommen, du hast gerade eine Push-Anforderung gestellt, nachdem du den Upstream-Branch gepullt und die Konflikte bearbeitet hast. Du denkst, du bist fertig, aber nein, in der Tat. Du merkst überrascht, dass der Besitzer des Upstream-Repo gerade einen neuen Commit e gemacht hat, als du Codes gepullt hast. Jetzt sieht die Situation so aus:

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

OK. Jetzt musst du die neuen Commits erneut in dein Repo pullen und eine neue Push-Anfrage stellen. Und vergiss nicht, dass es neue Codes im Upstream geben könnte... Theoretisch könntest du endlos in einer Schleife stecken bleiben.

Und empirisch betrachtet könntest du schließlich eine gut gemachte Push-Anforderung ohne Konflikte stellen. Glückwunsch, aber es gibt Hunderte von Push-Anforderungen. Wenn der Besitzer zuerst eine andere Push-Anfrage akzeptiert, musst du erneut pullen und pushen.

---

Letztendlich muss eine Beitrag geleistet werden.

• Konflikte beseitigen.
• Branch kombinieren.

Und es muss vom Besitzer gemacht werden. Andernfalls muss der Besitzer:

• Einen neuen Code eines Mitwirkenden genehmigen.
• Die Art des Mitwirkenden zur Konfliktlösung genehmigen.

Aber genau wie das Beispiel könnte es weitere Konflikte geben, wenn der Mitwirkende Konflikte löst.

Also ist die pull-Operation natürlich die Wahl. Deshalb gibt es eine pull-Anforderung, aber keine push-Anforderung.

Answer 5

Ein Pull-Request generiert eine Anfrage, die das Repository auffordert, Ihre Änderungen zu ziehen.