Prüfen und Übermitteln von Pull Requests

  • 5 Minuten

Mit Pull Requests (PRs) bringen Sie Ihr Wissen auf die Learn-Plattform. Sie haben einen PR erstellt, aber dieser wurde noch nicht an die PR-Warteschlange des Zielrepositorys übermittelt. Wie bei vielen Open-Source-Projekten gibt es eine Reihe von Überprüfungen und Reviews, die durchgeführt werden, um Änderungen vor der Veröffentlichung zu prüfen.

Aufbau eines PR

Screenshot of an open pull request.

Eine PR zeigt dem oder der GitHub-Benutzer*in, der oder die den PR erstellt hat, das Zielrepository und den Branch, in dem der PR erstellt wurde. PRs enthalten mehrere Registerkarten oben, einschließlich:

  • Registerkarte Conversation: Auf diesem Dashboard können Sie Kommentare von anderen Mitwirkenden anzeigen und beantworten, sehen eine Liste der Benachrichtigungen während des Erstellungs- und Reviewprozesses und können die Kommentarautomatisierung zum Ausführen von Aktionen verwenden.
  • Registerkarte Commits: Hier werden die Änderungen aufgezeichnet, die an diesem Branch vorgenommen wurden.
  • Registerkarte Files changed: Hier finden Sie einen Vergleich der geänderten Dateien im PR mit der vorherigen Version.

Achten Sie auf die Registerkarte „Conversation“, auf der alle Aktualisierungen oder Benachrichtigungen angezeigt werden, und alle Diskussionen zwischen Ihnen, den Reviewer*innen und anderen Mitwirkenden. Sie können hier auch Hashtagkommentare hinzufügen, um Aktionen auszuführen, z. B. um anzugeben, dass der PR freigegeben und bereit ist, geprüft und gemergt zu werden, oder ihn zurückzuhalten, wenn der Prozess angehalten werden soll.

PRs weisen häufig Bezeichnungen für den Status auf, z. B. draft für Entwurfs-PRs, die noch nicht zum Review bereit sind, oder do-not-merge für neue oder ungeprüfte PRs.

Überprüfen

Bevor Ihr PR mit dem Zielbranch gemergt werden kann, ist es möglicherweise erforderlich, einen oder mehrere PR-Validierungsprozesse zu durchlaufen. Nachdem Sie „Create pull request“ ausgewählt haben, führt GitHub die für Ihr Repository konfigurierten Validierungen aus. Nach Abschluss des Validierungsprozesses werden die Ergebnisse im PR angezeigt.

Validierungsprozesse variieren je nach Umfang der vorgeschlagenen Änderungen und den Regeln des Zielrepositorys. Nachdem Sie Ihren PR übermittelt haben, können Sie davon ausgehen, dass mindestens eine der folgenden Validierungen erfolgt:

  • Mergebarkeit: Zunächst wird ein grundlegender GitHub-Mergetest durchgeführt, um zu überprüfen, ob die vorgeschlagenen Änderungen in Ihrem Branch mit dem Zielbranch in Konflikt stehen. Wenn der PR angibt, dass dieser Test fehlgeschlagen ist, müssen Sie den Inhalt überarbeiten, der den Mergekonflikt verursacht, bevor die Verarbeitung fortgesetzt werden kann.
  • Lizenzvereinbarung für Mitwirkende (CLA): Wenn Sie an einem öffentlichen Repository mitwirken und kein*e Microsoft-Angestellte*r sind, werden Sie je nach Umfang der vorgeschlagenen Änderungen möglicherweise aufgefordert, eine kurze CLA auszufüllen, wenn Sie zum ersten Mal einen PR an dieses Repository übermitteln. Nachdem der CLA-Schritt erfolgt ist, wird Ihr PR verarbeitet.
  • Bezeichnung: Bezeichnungen werden automatisch auf Ihren PR angewendet, um den Status Ihres PR anzugeben, während dieser den Validierungsworkflow durchläuft. Beispielsweise können neue PRs automatisch mit der Bezeichnung „do-not-merge“ versehen werden, die angibt, dass der PR die Validierungs-, Review- und Freigabeschritte noch nicht abgeschlossen hat.
  • Validierung und Erstellung: Automatische Prüfungen verifizieren, ob Ihre Änderungen die Validierungstests bestehen. Die Validierungstests führen möglicherweise zu Warnungen oder Fehlern, sodass Sie Änderungen an einer oder mehreren Dateien in Ihrem PR vornehmen müssen, bevor dieser gemergt werden kann. Die Validierungstestergebnisse für das Review werden Ihrem PR als Kommentar hinzugefügt und möglicherweise auch per E-Mail an Sie gesendet.
  • Staging: Die Artikelseiten, die von Ihren Änderungen betroffen sind, können bei erfolgreicher Validierung und Erstellung automatisch in einer Stagingumgebung zur Überprüfung bereitgestellt werden. Vorschau-URLs erscheinen in einem PR-Kommentar.
  • Automatisches Mergen: Der PR kann automatisch gemergt werden, wenn er die Validierungstests bestanden hat und bestimmte Kriterien erfüllt. In diesem Fall müssen Sie nichts mehr tun.

Prüfen und Freigeben

Sie haben es fast geschafft. Nachdem die PR-Verarbeitung abgeschlossen wurde, empfiehlt es sich, die Ergebnisse zu prüfen (z. B. PR-Kommentare, Vorschau-URLs), um festzustellen, ob weitere Änderungen erforderlich sind, bevor Sie den PR zum Mergen freigeben. Wenn ein*e PR-Reviewer*in Ihren PR geprüft hat, kann diese*r auch Feedback über Kommentare mitteilen, wenn noch offene Issues oder Fragen vorliegen, die den Merge verhindern.

Verwenden Sie die Kommentarautomatisierung, um wichtige Aktionen im PR auszuführen. Mit der Kommentarautomatisierung können Benutzer*innen ihren PRs die entsprechende Bezeichnung zuweisen, um den Status zu aktualisieren oder zu kategorisieren. Wenn Sie in einem Repository arbeiten, in dem die Kommentarautomatisierung implementiert wurde, verwenden Sie die Hashtagkommentare, um Bezeichnungen zuzuweisen oder zu ändern, PRs zu schließen oder den Merge anzuhalten. Wenn Sie beispielsweise mit dem Vornehmen von Änderungen fertig sind, geben Sie den Kommentar „#sign-off“ an, um Ihre PR-Bezeichnung von do-not-merge in ready-for-review. zu ändern.

Verwenden Sie die Kommentare in der folgenden Tabelle, um wichtige Aktionen in Ihrem PR auszuführen:

Hashtagkommentar Was es tut
#sign-off Dieser Kommentar weist automatisch die Bezeichnung ready-to-merge zu, damit die Reviewer*innen im Repository wissen, dass der PR bereit fürs Review bzw. Mergen ist.

Wenn Sie nicht der oder die aufgeführte Autor*in sind und versuchen, einen PR für ein öffentliches Repository mit dem Kommentar #sign-off freizugeben, wird der PR mit einem Hinweis aktualisiert, dass nur der oder die Autor*in die Bezeichnung zuweisen kann.
#hold-off Dieser Kommentar entfernt die Bezeichnung ready-to-merge, falls Sie Ihre Meinung ändern oder einen Fehler machen.
#please-close Dieser Kommentar schließt den PR, wenn Sie beschließen, dass die Änderungen nicht gemergt werden sollen.
#please-open Dieser Kommentar öffnet einen geschlossenen PR oder ein Issue wieder.

Sie müssen den Kommentar „#sign-off“ eingeben, um Ihre Änderungen zu mergen. Selbst wenn alle Reviews und Validierungsprüfungen bestanden werden, sind Sie dafür verantwortlich, diesen Kommentar zu verwenden, um den PR-Reviewer*innen und Repositoryadministrator*innen mitzuteilen, dass die Änderungen von Ihrer Seite aus bereit zum Mergen sind. Wenn die Reviewer*innen beschließen, dass Ihr PR fehlerfrei und freigegeben ist, werden Ihre Änderungen wieder mit dem übergeordneten Branch gemergt, und der PR wird geschlossen.

Screenshot of the comment box on a PR with #sign-off typed into the comment field and the Comment button highlighted.

Veröffentlichung

Bedenken Sie, dass Ihr PR von einem oder einer PR-Reviewer*in gemergt werden muss, bevor die Änderungen in die nächste geplante Veröffentlichungsausführung aufgenommen werden können. Normalerweise werden PRs in der Reihenfolge der Übermittlung geprüft und gemergt.

Nachdem Ihre Beiträge genehmigt und zusammengeführt wurden, werden sie vom Veröffentlichungsprozess übernommen. Je nach Team, das das Repository verwaltet, an dem Sie mitwirken, können die Veröffentlichungszeiten variieren. In der Regel erfolgt die Veröffentlichung jedoch mindestens einmal pro Wochentag. Es kann bis zu 45 Minuten dauern, bis Artikel nach der Veröffentlichung online erscheinen.

Sobald Ihre Änderungen veröffentlicht wurden, erscheinen sie auf Microsoft Learn. Dann können andere mit dem Lernen beginnen.

Szenario: Veröffentlichen von Änderungen in Azure App Service

Aufgrund Ihrer Erfahrung haben Sie eine Möglichkeit erkannt, nützliche Informationen zu einer App Service-Dokumentationsseite hinzuzufügen. Hierfür haben Sie einen PR erstellt. Sie sind nun bereit, Ihren PR prüfen zu lassen und freizugeben, um Ihre Bearbeitungen zu veröffentlichen.