Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Pull Request-Reviewprozess

Bemerkung

Diese Seite soll einen Einblick in den von uns angestrebten Prozess des Reviews von Pull Requests (PRs) geben. Sie richtet sich daher in erster Linie an Engine-Maintainer, die für das Reviewen und die Genehmigung von Pull Requests verantwortlich sind. Dennoch ist ein Großteil des Inhalts auch für potenzielle Mitwirkende nützlich, die wissen wollen, wie sie sicherstellen können, dass ihr PR gemergt wird.

Im Groben sieht der ideale Lebenszyklus eines Pull Requests wie folgt aus:

  1. Ein Mitwirkender öffnet einen PR, der ein bestimmtes Problem behebt (im Idealfall schließt er eine GitHub-Issue oder implementiert ein Proposal).

  2. Andere Mitwirkende geben Feedback zum PR (einschließlich des Reviews und/oder Genehmigung des PRs, je nach Bedarf).

  3. Ein Engine-Maintainer prüft den Code und gibt Feedback, fordert Änderungen an oder genehmigt den Pull Request, je nach Bedarf.

  4. Ein weiterer Mitwirkender prüft den Code mit Schwerpunkt auf Stil/Klarheit und gibt ihn frei, sobald er zufrieden ist.

  5. Ein Teamleiter oder ein Mitglied des Produktionsteams mergt den Pull Request, wenn er überzeugt ist, dass er ausreichend geprüft wurde.

In diesem Dokument werden die Schritte 2, 3, 4 und 5 näher erläutert. Für eine detailliertere Erklärung des Pull Request-Workflows lesen Sie bitte das Dokument über den Pull Request-Workflow.

Bemerkung

In der Praxis können diese Schritte ineinander übergehen. Oftmals geben die Maintainer gleichzeitig Kommentare zum Code-Stil und zur Code-Qualität ab und genehmigen einen Pull Request für beide.

Normalerweise besteht die erste Interaktion bei einem Pull Request darin, dass ein Engine-Maintainer dem Pull Request Tags zuweist und ihn zum Review durch jemanden kennzeichnet, der mit dem betreffenden Codebereich vertraut ist.

Engine-Maintainer sind Leute, die "Mitglieder" des Godot-Projekt-Repositorys auf GitHub sind und/oder die auf der Teams-Seite auf der Godot-Website aufgeführt sind. Maintainer sind für einen bestimmten Bereich der Engine verantwortlich. In der Regel bedeutet dies, dass ihnen mehr Vertrauen entgegengebracht wird, wenn es darum geht, Pull Requests zum Mergen zu genehmigen und zu empfehlen.

Auch wenn Sie kein Maintainer sind, können Sie helfen, indem Sie den Code überprüfen, Feedback zu PRs geben und PRs lokal auf Ihrem Rechner testen, um zu bestätigen, dass sie wie vorgesehen funktionieren. Viele der derzeit aktiven Maintainer haben mit diesen Dingen angefangen, bevor sie Maintainer wurden.

Code-Reviews und Tests

Im Folgenden finden Sie eine Liste von Dingen, die Mitwirkende und Engine-Maintainer tun können, um ein substantielles Code-Review eines Pull Requests durchzuführen.

Bemerkung

Wenn Sie ein Code-Review durchführen wollen, aber nicht alles auf dieser Liste tun können, sagen Sie das in Ihrem Review-Kommentar. Zum Beispiel ist es immer noch sehr hilfreich, Kommentare zum Code abzugeben, auch wenn Sie den Pull Request nicht lokal bauen können, um ihn zu testen (oder umgekehrt). Fühlen Sie sich frei, den Code zu reviewen, denken Sie nur daran, am Ende Ihres Reviews zu vermerken, dass Sie nur den Code angeschaut haben und die Änderungen nicht lokal getestet haben.

1. Bestätigen Sie, dass das Problem besteht

PRs müssen Probleme lösen und Probleme müssen dokumentiert werden. Stellen Sie sicher, dass der Pull Request einen Link zu einem Bug oder Proposal enthält und diesen schließt (oder zumindest anspricht). Wenn dies nicht der Fall ist, sollten Sie den Mitwirkenden bitten, die einleitende Nachricht des PRs zu aktualisieren, um das Problem, das der PR lösen soll, genauer zu erklären.

Bemerkung

Es sollte klar sein, warum ein Pull Request benötigt wird, bevor er gemergt wird. Dies hilft den Prüfern bei der Feststellung, ob ein PR das tut, was er vorgibt zu tun, und es hilft zukünftigen Mitwirkenden, zu verstehen, warum der Code so ist, wie er ist.

2. Testen Sie den PR und suchen Sie nach Regressions-Bugs

Auch wenn strenge Code-Reviews und CI dazu beitragen, dass alle Pull Requests wie beabsichtigt funktionieren, passieren Fehler, und manchmal bringen Mitwirkende Code ein, der nicht nur ein Problem löst, sondern auch ein Problem schafft. Maintainer werden es vermeiden, Code zu mergen, der einen Regressions-Bug enthält, selbst wenn er das Problem wie beabsichtigt löst.

Stellen Sie beim Review eines Pull Requests sicher, dass der PR das tut, was er behauptet (d.h. den verlinkten Bug behebt oder das neue Feature implementiert) und dass nichts außerhalb des PR-Ziels durch die Änderung kaputt geht. Sie können dies tun, indem Sie den Editor starten und einige gängige Features des Editors ausprobieren (Objekte zu einer Szene hinzufügen, GDScript ausführen, Menüs öffnen und schließen usw.). Achten Sie beim Review des Codes auch auf verdächtige Änderungen in anderen Teilen der Engine. Manchmal schleichen sich während des Rebasings Änderungen ein, deren sich die Mitwirkenden nicht bewusst sind.

3. Führen Sie ein Code-Review durch

Code-Reviews werden in der Regel von Personen durchgeführt, die bereits Erfahrung in einem bestimmten Bereich haben. Sie können vielleicht Ideen liefern, um den Code schneller, besser organisiert oder idiomatischer zu machen. Aber auch wenn Sie nicht sehr erfahren sind, können Sie ein Code-Review durchführen, um Feedback im Rahmen dessen zu geben, was Sie selbst reviewen können. Dies ist für den Maintainer des Bereichs wertvoll (da ein zweiter Blick auf ein Problem immer hilfreich ist), und es ist auch für Sie hilfreich, da es Ihnen hilft, sich mit diesem Bereich des Codes vertrauter zu machen und Ihnen zeigt, wie andere Leute Probleme lösen. Tatsächlich ist das Review des Codes von erfahrenen Engine-Maintainern eine großartige Möglichkeit, die Codebasis kennen zu lernen.

Hier sind einige Dinge, an die Sie denken und auf die Sie achten sollten, wenn Sie den Code reviewen:

  • Berührt der Code nur die im PR (und in der Commit-Nachricht) beschriebenen Bereiche?

    Es kann verlockend sein, wahllos Dinge im Code zu korrigieren, wenn man sie sieht. Dies kann jedoch schnell dazu führen, dass ein Pull Request schwer zu reviewen wird, und es kann es erschweren, die Commit-Historie zu durchsuchen. Kleine Ausbesserungen neben dem verwandten Bereich sind in Ordnung, aber oft werden Bugs, die man unterwegs findet, besser in eigenen PRs behoben.

  • Verwendet der Code Godots eigene APIs und Muster korrekt?

    Konsistenz ist sehr wichtig, und eine Lösung, die bereits in der Codebasis vorhanden ist, ist einer Ad-hoc-Lösung vorzuziehen.

  • Sind Kernbereiche von der Änderung betroffen?

    Manchmal kann ein PR, der ein lokales Problem lösen soll, weitreichende Auswirkungen haben, die weit über seinen Geltungsbereich hinausgehen. In der Regel ist es am besten, Codeänderungen dort vorzunehmen, wo das Problem auftritt. Wenn Sie der Meinung sind, dass die Lösung Änderungen außerhalb des Geltungsbereichs des Problems erfordert, ist es in der Regel am besten, die Meinung eines Teamleiters einzuholen, der vielleicht eine andere Idee hat, wie das Problem zu lösen ist.

4. Iterieren Sie mit dem Mitwirkenden und verbessern Sie den PR

Maintainer sollten Feedback und Verbesserungsvorschläge geben, wenn sie Dinge im Code entdecken, die sie gerne geändert hätten. Vorzugsweise sollten die Vorschläge in der Reihenfolge ihrer Wichtigkeit erfolgen: Zuerst sollten sie sich mit dem allgemeinen Code-Design und dem Lösungsansatz für das Problem befassen, dann sicherstellen, dass der Code den Best Practices der Engine entspricht, und zuletzt das Code Style Review durchführen.

Bemerkung

Kommunizieren Sie Hindernisse, die einem Merge entgegenstehen, frühzeitig im Review-Prozess.

Wenn der PR klare Blocker hat oder aus anderen Gründen wahrscheinlich nicht gemergt wird, sollte diese Tatsache so früh und klar wie möglich kommuniziert werden. Wir wollen vermeiden, dass wir die Leute hinhalten, nur weil wir uns schlecht dabei fühlen würden, "Sorry, nein" zu sagen.

Wenn Sie Pull Requests reviewen, denken Sie an den Godot-Verhaltenskodex. Insbesondere das Folgende:

  • Höflichkeit wird zu jeder Zeit erwartet. Seien Sie freundlich und zuvorkommend.

  • Gehen Sie bei anderen immer von positiven Absichten aus.

  • Feedback ist immer willkommen, aber halten Sie Ihre Kritik konstruktiv.

Hier sind einige Dinge, die Sie vermeiden sollten, wenn Sie über einen Pull Request mit einem Mitwirkenden iterieren:

  • Überflüssige Doppelreviews.

    Mit anderen Worten: Reviewen Sie den gesamten PR auf einmal und vermeiden Sie es, endlose Male zurückzukommen, um auf Probleme hinzuweisen, die Sie bereits beim ersten Reviewen hätten feststellen können. Natürlich lässt sich das nicht immer vermeiden, aber wir sollten versuchen, alles auf einmal zu erfassen.

  • Übermäßig pingelig sein.

    Die Codequalität kann je nach dem Bereich der Engine, in dem Sie arbeiten, flexibel sein. Im Allgemeinen ist unser Standard für die Codequalität in Kernbereichen und in Performance-sensiblen Bereichen viel höher als z.B. im Editor-Code.

  • Erweiterung des Geltungsbereichs eines Pull Requests.

    Es kann hilfreich sein, den Kontext oder verwandte/ähnliche Probleme oder Vorschläge zu nennen, die auf ähnliche Weise behoben werden können, aber der Zusatz "Wir können auch das da drüben beheben, wenn wir schon dabei sind" oder "Könnten wir das auch noch hinzufügen?" ist dem Mitwirkenden gegenüber nicht immer fair. Benutzen Sie Ihr Urteilsvermögen, wenn Sie entscheiden, ob zusätzliche Korrekturen innerhalb des Umfangs liegen, aber versuchen Sie, den Umfang so nah wie möglich am ursprünglichen Pull Request zu halten.

Und schließlich sollten Sie sich nicht unter Druck gesetzt fühlen, den PR ganz allein zu bewältigen. Bitten Sie im Godot-Mitwirkenden-Chat, im entsprechenden Kanal oder in #general um Hilfe. Es kann sein, dass andere Teams bereits für das Reviewen markiert sind, also können Sie auch warten oder um deren Hilfe bitten.

5. Den Pull Request genehmigen

Wenn Sie nach dem Reviewen des Codes der Meinung sind, dass der Code bereit ist, in die Engine gemergt zu werden, dann "genehmigen" Sie ihn. Stellen Sie sicher, dass Sie auch einen Kommentar abgeben und die Art Ihres Reviews beschreiben (d.h. sagen Sie, ob Sie den Code lokal ausgeführt haben, ob Sie sowohl den Stil als auch die Korrektheit überprüft haben, usw.). Auch wenn Sie kein Engine-Maintainer sind, signalisiert die Genehmigung eines Pull Requests anderen, dass der Code gut ist und wahrscheinlich das Problem löst, das der PR beschreibt. Einen Pull Request als Nicht-Engine-Maintainer zu genehmigen, ist keine Garantie dafür, dass der Code gemergt wird, andere Leute werden ihn trotzdem reviewen, also seien Sie nicht schüchtern.

Codestil-Review

Im Allgemeinen ist es unser Ziel, ein Code-Review vor einem Stil/Verständlichkeits-Review durchzuführen, da die Mitwirkenden in der Regel wissen wollen, ob ihr allgemeiner Ansatz akzeptabel ist, bevor sie sich die Mühe machen, pingelige Änderungen am Stil vorzunehmen. Mit anderen Worten, die Maintainer sollten die Mitwirkenden nicht bitten, den Stil des Codes zu ändern, der in späteren Reviews möglicherweise neu geschrieben werden muss. Ebenso sollten Maintainer es vermeiden, Mitwirkende zu bitten, PRs zu überarbeiten, wenn der PR noch nicht gereviewt wurde.

Trotz alledem: Nicht jeder fühlt sich jedoch sicher genug, um die Korrektheit des Codes zu reviewen. In diesem Fall sind Kommentare zu Stil und Klarheit des Codes vor einem umfassenderen Code-Review durchaus angebracht und mehr als willkommen.

In der Praxis kann das Codestil-Review als Teil des substantiellen Code-Reviews durchgeführt werden. Wichtig ist, dass sowohl der inhaltliche Code als auch der Codestil überprüft und berücksichtigt werden müssen, bevor ein Pull Request gemergt wird.

Achten Sie beim Reviewen des Codestils besonders darauf, dass der Pull Request den Richtlinien für den Codestil folgt. Während clang-format und verschiedene CI-Prüfungen viele Inkonsistenzen abfangen können, sind sie weit davon entfernt, perfekt zu sein und sind nicht in der Lage, einige Probleme zu erkennen. Zum Beispiel sollten Sie überprüfen, dass:

  • Der Stil der Header-Includes beachtet wird.

  • Bezeichner snake_case verwenden und unseren Namenskonventionen folgen.

  • Methodenparameter mit p_* oder r_* beginnen (falls sie zur Rückgabe eines Wertes verwendet werden).

  • Klammern in angemessener Weise verwendet werden, auch für Einzeiler-Conditionals.

  • Der Code die richtigen Abstände verwendet (genau eine Leerzeile zwischen den Methoden, keine unnötigen Leerzeilen innerhalb von Methodenrümpfen).

Bemerkung

Diese Liste ist nicht vollständig und hat auch nicht den Anspruch, vollständig zu sein. Eine vollständige Liste der Regeln finden Sie im verlinkten Style Guide Dokument. Denken Sie daran, dass clang-format möglicherweise nicht die Dinge erkennt, die Sie sich erhoffen, also seien Sie aufmerksam und versuchen Sie, ein Gefühl dafür zu entwickeln, was genau es erkennen kann und was nicht.

Mergen von Pull Requests

Im Allgemeinen sollten Pull Requests nur von Mitgliedern des Produktionsteams oder Teamleitern für Pull Requests in ihrem Bereich der Engine gemergt werden. Zum Beispiel könnte der Leiter des Netzwerkteams einen Pull Request für das Netzwerk mergen, der keine wesentlichen Änderungen an den nicht-netzwerkbezogenen Abschnitten des Codes vornimmt.

In der Praxis ist es am besten, auf ein Mitglied des Produktionsteams zu warten, um den Pull Request zu mergen, da sie ein genaues Auge auf die gesamte Codebasis haben und wahrscheinlich ein besseres Gespür dafür haben, mit welchen anderen kürzlichen/künftigen Änderungen dieser Pull Request in Konflikt stehen könnte (oder andere Gründe, die es sinnvoll machen, den Pull Request zu verzögern). Sie können gerne einen Kommentar hinterlassen, dass der PR zum Mergen bereit sein sollte.

Im Folgenden sind die Schritte aufgeführt, die vor dem Mergen eines Pull Requests zu beachten sind. Der Umfang, in dem Sie diese Schritte befolgen, kann bei einfachen/geradlinigen Pull Requests flexibel sein, aber bei komplexen oder riskanten Pull Requests sollten sie sorgfältig durchgeführt werden.

Als Mitwirkender können Sie dazu beitragen, einen Pull Request voranzubringen, indem Sie einige dieser Schritte selbst ausführen.

1. Feedback von den richtigen Personen/Teams einholen

Die Mitglieder des Produktionsteams sollten sicherstellen, dass sich die richtigen Personen einen Pull Request ansehen, bevor er gemergt wird. In einigen Fällen kann es erforderlich sein, dass sich mehrere Personen dazu äußern. In anderen Fällen ist nur eine einzige inhaltliche Genehmigung erforderlich, bevor der Code gemergt werden kann.

Versuchen Sie im Allgemeinen nicht, Dinge aufgrund eines einzigen Reviews zu mergen, besonders wenn es Ihr eigenes ist. Holen Sie eine zweite Meinung von einem anderen Maintainer ein, und stellen Sie sicher, dass alle Teams, die davon betroffen sein könnten, durch die Reviewer angemessen vertreten sind. Wenn ein Pull Request zum Beispiel die Dokumentation erweitert, ist es oft sinnvoll, ihn von den Bereichs-Maintainern auf sachliche Korrektheit und von den Dokumentations-Maintainern auf Formatierung, Stil und Grammatik prüfen zu lassen.

Eine gute Faustregel ist, dass mindestens ein Fachexperte den Pull Request für die Korrektheit und mindestens ein anderer Maintainer den Pull Request für den Codestil genehmigt haben sollte. Jede dieser Personen könnte die Person sein, die den Pull Request mergen wird.

Vergewissern Sie sich, dass die Reviews und Genehmigungen von Personen stammen, die in diesem speziellen Bereich der Engine kompetent sind. Es ist möglich, dass sogar ein langjähriges Mitglied der Godot-Organisation ein Review abgegeben hat, ohne über das entsprechende Fachwissen zu verfügen.

Bemerkung

Eine einfache Möglichkeit, PRs zu finden, die zum Mergen bereit sein könnten, ist das Filtern nach genehmigten PRs und das Sortieren nach "kürzlich aktualisiert". Im Godot-Haupt-Repository können Sie zum Beispiel diesen Link verwenden.

2. Einholen von Feedback aus der Community

Wenn ein Pull Request Schwierigkeiten hat, Reviewer anzuziehen, müssen Sie sich vielleicht breiter aufstellen und um Hilfe beim Reviewen bitten. Erwägen Sie folgenden Personen zu fragen:

  • die Person, die den Bug gemeldet hat, ob der Pull Request den Bug für sie behebt,

  • Mitwirkende, die diese Datei kürzlich bearbeitet haben, ob sie einen Blick darauf werfen könnten, oder

  • einen erfahreneren Maintainer aus einem anderen Bereich, ob dieser ein Feedback geben könnte.

3. Git-Checkliste

  • Stellen Sie sicher, dass der PR in einem einzelnen Commit erstellt wird.

    Wenn jeder Commit in sich abgeschlossen ist und verwendet werden kann, um eine saubere und funktionierende Version der Engine zu erstellen, kann es in Ordnung sein, einen Pull Request mit mehreren Commits zu mergen, aber im Allgemeinen verlangen wir, dass alle Pull Requests nur einen Commit haben. Dies hilft uns, die Git-Historie sauber zu halten.

  • Korrekturen, die während des Review-Prozesses vorgenommen werden, müssen in den Haupt-Commit gesquasht werden.

    Bei PRs mit mehreren Commits sollten Sie darauf achten, dass die Korrekturen in die entsprechenden Commits integriert werden und nicht einfach oben draufgepackt werden.

  • Stellen Sie sicher, dass der PR keine Merge-Konflikte hat.

    Mitwirkende müssen ihre Änderungen möglicherweise auf den entsprechenden Branch (z.B. master oder 3.x) rebasen und Merge-Konflikte manuell beheben. Selbst wenn es keine Merge-Konflikte gibt, kann es sein, dass Mitwirkende vor allem alte PRs rebasen müssen, da der GitHub-Konflikt-Checker möglicherweise nicht alle Konflikte erkennt oder sich die CI seit der ursprünglichen Ausführung geändert hat.

  • Prüfen Sie, ob die Attribution des Commits korrekt ist.

    Wenn ein Mitwirkender eine Autorensignatur verwendet, die nicht in seinem GitHub-Konto aufgeführt ist, verknüpft GitHub den gemergten Pull Request nicht mit seinem Konto. Dies verhindert, dass er in der GitHub-Historie richtig gewürdigt wird, und lässt ihn auf der GitHub-Benutzeroberfläche selbst nach mehreren Beiträgen wie einen neuen Mitwirkenden erscheinen.

    Letztendlich bleibt es dem Benutzer überlassen, ob er das Problem beheben möchte, aber er kann dies tun, indem er den Git Commit mit der gleichen E-Mail verfasst, die er für sein GitHub-Konto verwendet, oder indem er die für den Git-Commit verwendete E-Mail zu seinem GitHub-Profil hinzufügt.

  • Auf korrekte Commit-Messages achten.

    Wir haben zwar keine sehr strengen Regeln für Commit-Messages, aber wir verlangen trotzdem, dass sie kurz, aber aussagekräftig sind und korrektes Englisch verwenden. Als Maintainer haben Sie wahrscheinlich schon oft genug welche geschrieben, um zu wissen, wie man sie erstellt, eine allgemein gute Form wäre "Fix <issue> in <part of codebase>". Für eine detailliertere Empfehlung siehe die Seite contributing.md im Godot-Haupt-Repository.

4. GitHub-Checkliste

  • Ziel-Branch des PR validieren.

    Die meiste Godot-Entwicklung findet im master-Branch statt. Daher müssen die meisten Pull Requests gegen diesen Branch gestellt werden. Von dort aus können Pull Requests dann auf andere Branches zurückportiert werden. Achten Sie auf Leute, die PRs für die Version machen, die sie benutzen (z.B. 3.3) und leiten Sie sie an, eine Änderung gegen einen höherwertigen Branch (z.B. 3.x) zu machen. Wenn die Änderung nicht für den master-Branch gilt, kann der erste PR gegen den aktuellen Wartungs-Branch gemacht werden, wie 3.x. Es ist in Ordnung, wenn Leute mehrere PRs für jeden Ziel-Branch machen, besonders wenn die Änderungen nicht einfach zurückportiert werden können. Cherry-Picking ist auch eine Option, wenn möglich. Verwenden Sie die entsprechenden Labels, wenn der für den PR Cherrypicking möglich ist (z.B. cherrypick:3.x).

Bemerkung

Es ist möglich, den Ziel-Branch des PRs zu ändern, der bereits eingereicht wurde, aber seien Sie sich der Konsequenzen bewusst. Da sie nicht mit dem Push synchronisiert werden kann, wird die Änderung des Ziel-Branchs unweigerlich die gesamte Liste der Maintainer zum Reviewen markieren. Es kann auch dazu führen, dass die CI nicht mehr richtig läuft. Ein Push sollte hier Abhilfe schaffen, aber wenn nichts anderes hilft, sollten Sie einen neuen, frischen PR eröffnen.

  • Vergewissern Sie sich, dass der entsprechende Milestone zugewiesen ist.

    Dadurch wird es offensichtlicher, welche Version die eingereichten Änderungen enthalten würde, sollte der Pull Request jetzt gemergt werden. Beachten Sie, dass der Milestone kein verbindlicher Vertrag ist und nicht garantiert, dass diese Version definitiv den PR enthalten wird. Wenn der Pull Request nicht vor der Freigabe der Version gemergt wird, wird der Milestone verschoben (und der PR selbst kann eine Änderung des Ziel-Branchs erfordern).

    Wenn Sie einen PR mit einem höheren Milestone als der aktuellen Version oder einem "Wildcard"-Milestone (z.B. "4.x") gemergt haben, stellen Sie sicher, dass Sie den Milestone auf die aktuelle Version aktualisieren.

  • Vergewissern Sie sich, dass die Einleitungs-Message des PR die magischen Worte "Closes #..." oder "Fixes #..." enthält.

    Diese verknüpfen den PR und die referenzierte Issue miteinander und erlauben es GitHub, die letztere automatisch zu schließen, wenn Sie die Änderungen mergen. Beachten Sie, dass dies nur für die PRs funktioniert, die auf den master-Branch abzielen. Bei anderen müssen Sie aufpassen und die zugehörigen Issues manuell schließen. Machen Sie dies mit einem "Fixed by #... " oder "Resolved by #... "-Kommentar, um den Vorgang für zukünftige Mitwirkende deutlich zu machen.

  • Für die Issues, die durch den PR geschlossen werden, fügen Sie den nächstgelegenen relevanten Milestone hinzu.

    Mit anderen Worten, wenn der PR auf den master-Branch abzielt, aber dann auch für 3.x ausgewählt wird, wäre das nächste 3.x-Release der passende Milestone für die geschlossene Issue.

5. Den Pull Request mergen

Wenn es für Sie angemessen ist, einen Pull Request zu mergen (d.h. Sie gehören zum Produktionsteam oder sind der Teamleiter für diesen Bereich), Sie zuversichtlich sind, dass der Pull Request ausreichend gereviewt wurde, und sobald Sie diese Schritte ausgeführt haben, können Sie fortfahren und den Pull Request mergen.