Prüfen und Übermitteln von Pull Requests
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
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 zum Ausführen von Aktionen hinzufügen, um beispielsweise anzugeben, dass der PR freigegeben ist und zunächst überprüft und anschließend gemergt werden kann oder noch zurückgehalten werden soll, wenn Sie den Prozess anhalten müssen.
PRs weisen häufig Bezeichnungen auf, um ihren Status anzugeben (z. B. draft für Entwurfs-PRs, die noch nicht für die Überprüfung bereit sind, oder do-not-merge für neue oder noch nicht überprü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 Pull Request erstellen ausgewählt haben, führt GitHub die für Ihr Repository konfigurierten Validierungen durch. 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 Microsoft-Angestellter 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 seinen Status anzugeben, während dieser den Validierungsworkflow durchläuft. Beispielsweise können neue PRs automatisch mit der Bezeichnung
do-not-mergeversehen 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 die Überprüfung 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 und 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 im Repository wissen, dass der PR bereit für das Überprüfen bzw. Mergen ist. Wenn Sie nicht der aufgeführte Autor 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 Autor 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-Reviewern und Repositoryadministratoren 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.
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.