number - github tag



Sind abhängige Pull-Anfragen in Github möglich? (1)

Momentan arbeite ich an einer wirklich großen Pull-Anfrage. Um Code-Reviews irgendwie überschaubar zu halten, sollte der gesamte Pull-Auftrag in isolierte Teile aufgeteilt werden, die jedoch voneinander abhängig sind.

Ein Beispiel wäre:

  • Pullanforderung 1 : Schnittstellen erstellen: Schnittstelle A & B und Restrukturierung von Code
  • Pullanforderung 2 : Implementierung von Schnittstelle A und Tests (abhängig von der Pullanforderung1)
  • Pullanforderung 3 : Implementierung der Schnittstelle B und Tests (abhängig von der Pullanforderung2)
  • Pull-Anfrage 4 : Mischtest von Implementierungen (abhängig von 2 + 3)

Gibt es eine Möglichkeit in Github, alle vier Pull-Anforderungen gleichzeitig mit Abhängigkeiten abzulegen?


Soweit ich sehen kann, ist dies unmöglich und meiner Meinung nach einer der größten Nachteile von GitHub im Vergleich zu anderen Codeüberprüfungstools. Gerrit richtet automatisch abhängige Code-Überprüfungen ein, wenn Sie Commits ausführen, die voneinander abhängig sind. In Phabricator ist dies eher ein Schmerz, aber immer noch möglich.

Es ist auch gut zu bedenken, dass es mehrere Möglichkeiten gibt, wie GitHub-PRs verwendet werden. Die normale Open-Source-Collaboration-Methode besteht darin, ein Repo zu verzweigen und eine Cross-Repo-Pull-Anforderung zu übermitteln. In anderen Fällen (z. B. innerhalb einer Organisation) können Sie jedoch Pull-Anforderungen für Unterschiede in demselben Repository einreichen. Ich denke, in einem einzigen Repository ist es sinnvoller, etwas in Abhängigkeit von abhängigen Pull-Requests zu erhalten, da Sie die Commit / Branch-Struktur innerhalb dieses Repos einrichten können.

Hier ist ein Blog-Post, der beschreibt, wie man einige Vorteile von abhängigen Pull-Anfragen erhält. Ich denke, alle Commits müssen im selben Repo sein: http://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/

Eine Zusammenfassung:

  • Erstellen Sie zum Senden von 5 abhängigen Pull-Anforderungen eine Verzweigungshierarchie mit fünf Ebenen, und senden Sie jede PR als diese Verzweigung basierend auf der vorherigen Verzweigung.
  • Um die Überprüfung 2 von 5 zu aktualisieren, drücken Sie eine Aktualisierung auf Zweig 2 und führen Sie dann 3 Zusammenführungsvorgänge durch, um die Änderungen in die Überprüfungen 3, 4 und 5 zu integrieren.
  • Sie müssen alle Änderungen gleichzeitig landen, da GitHub die Aktualisierung des Zielzweigs von PRs nicht unterstützt. In dem Beispiel wurden alle 5 Codeüberprüfungen als einmaliges Commit gelandet. GitHub unterstützt jetzt die Aktualisierung des Basiszweigs einer PR, sodass die PRs jeweils einzeln gelandet werden können.

Dieser Ansatz scheint gut zu funktionieren für riesige Änderungen, die am besten in kleineren Teilen git rebase -i (obwohl die Aufrechterhaltung einer n- git rebase -i Verzweigungshierarchie im Vergleich zu git rebase -i ein Schmerz ist), aber ein " Code-Überprüfungs-Pipeline ", in der abhängige Unterschiede in verschiedenen Überprüfungsphasen vorhanden sein können und bei deren Überprüfung frühere landen können.

Einige andere Internet-Ressourcen, die auch die Einschränkung aufzuzeigen scheinen:

https://www.quora.com/Is-there-a-good-system-for-adding-multiple-pull-requests-to-GitHub

https://muffinresearch.co.uk/how-do-you-deal-with-dependent-branches-on-github/

Ich verstehe, dass Leute, die GitHub PRs verwenden, im Allgemeinen nur versuchen, ihren Workflow so zu strukturieren, dass sie sich nicht auf abhängige Codeüberprüfungen verlassen. Einige Beispiele:

  • Anstatt eine Änderung in unabhängig überprüfbare inkrementelle Schritte aufzuteilen, reichen Sie sie als monolithische Codeüberprüfung ein, die auf einmal landet. Mit GitHub können Sie Codeüberprüfungen zwar in mehrere Commits aufteilen, die der Überprüfer anzeigen kann, sie können jedoch nicht unabhängig genehmigt / gelandet werden.
  • Versuchen Sie, Ihre Arbeit so zu strukturieren, dass Sie Änderungen an nicht zusammenhängenden Teilen des Codes vornehmen und diese in unabhängige Zweigstellen ablegen, die Sie zum Senden unabhängiger PRs verwenden können. Sie können immer noch einen lokalen Zweig mit allen durch Kirschpicking oder andere Methoden vorgenommenen Änderungen behalten.
  • Wenn Sie eine Änderung haben, die von einer herausragenden PR abhängt, warten Sie einfach, bis die PR akzeptiert und zusammengeführt wird, bevor Sie die neue PR absenden. Sie könnten irgendwo erwähnen, dass Sie eine andere PR haben, die von dieser abhängt, und dies könnte den Code-Reviewer dazu motivieren, früher zu dieser zu gelangen.




pull-request