[ English | English (United Kingdom) | 中文 (简体, 中国) | Indonesia | 한국어 (대한민국) | español (México) | Deutsch ]
Verwendung von Gerrit¶
Bemerkung
Dieser Abschnitt geht davon aus, dass Sie die Anleitung Einrichten Ihres Gerrit-Kontos abgeschlossen haben.
Gerrit erlaubt es Ihnen:
Erhalten Sie Bewertungen zu Ihren Änderungsvorschlägen für OpenStack-Repositories.
Beantragung von Bewertungen von bestimmten Community-Mitgliedern
Nehmen Sie schnelle Änderungen an Ihren Patches im Webui vor.
Eine Änderung vorantreiben¶
Bemerkung
Dies ist eine Schnellstartversion. Für eine ausführlichere Beschreibung, wie man klont, einen Patch erstellt und die Änderung vorantreibt, finden Sie hier eine Wegbeschreibung.
Im Folgenden finden Sie eine Liste der Befehle, die Sie für Ihren ersten Beitrag kennen müssen:
Um eine Kopie eines Repositories zu klonen:
git clone https://opendev.org/openstack/<PROJECT_NAME>
Bemerkung
Sie können die gleichen Repositories über die Suchfunktion hier finden: OpenStack git Repository Browser
Nachdem Sie den Abschnitt Setup and Learn GIT abgeschlossen haben, konfiguriert der folgende Befehl das Repository, um mehr über Gerrit zu erfahren, und installiert den Commit-Hook Change-I. Sie müssen dies nur einmal pro Repository tun, das Sie klonen:
git review -s
Um Ihren Entwicklungszweig zu erstellen (ersetzen Sie branch_name durch einen Namen Ihrer Wahl). Es ist besser, für jeden Patch einen neuen Zweig zu erstellen, als vom Master aus zu arbeiten:
git checkout -b <branch_name>
So überprüfen Sie die Dateien, die in Ihrem Zweig aktualisiert wurden:
git status
Um die Unterschiede zwischen Ihrem Zweig und dem Repository zu überprüfen:
git diff master
Angenommen, Sie haben keine neuen Dateien hinzugefügt, übertragen Sie alle Ihre Änderungen mit:
git commit -a
Lesen Sie die Zusammenfassung der Git Commit-Nachrichtenstruktur für Best Practices beim Schreiben der Commit-Nachricht. Wenn Sie bereit sind, Ihre Änderungen zur Überprüfung zu senden, verwenden Sie:
git review
Wenn dies erfolgreich ist, enthält die Git-Antwortnachricht eine URL, mit der Sie Ihre Änderungen verfolgen können.
Wenn Sie weitere Änderungen an derselben Überprüfung vornehmen müssen, können Sie diese mit:
git commit -a --amend
Dadurch werden die Änderungen unter dem gleichen Satz von Änderungen, die Sie zuvor vorgenommen haben, übernommen. Beachten Sie, dass Sie, um Ihre neueste Version zur Überprüfung zu senden, immer noch anrufen müssen:
git review
Nachverfolgung Ihrer Änderungen¶
Nachdem Sie Änderungen vorgeschlagen haben, können Sie diese unter Code Review verfolgen. Nach dem Einloggen sehen Sie ein Dashboard mit „Outgoing reviews“ für Änderungen, die Sie vorgeschlagen haben, „Ingoing reviews“ für Änderungen, die Sie überprüfen, und „Recently closed“, für die Sie entweder Reviewer oder Eigentümer waren.
Hinzufügen von Reviewern¶
Manchmal kann es Menschen geben, die Sie auf Ihren Patch einbeziehen möchten, weil sie ein persönliches Interesse haben oder Ihnen als Mentor helfen. Der einfachste Weg, sie wissen zu lassen, dass Sie einen neuen Patch oder ein neues Patchset hochgeladen hast, ist, sie als Reviewer im gerrit web-ui hinzuzufügen. Sie können sie nach Namen, gerrit E-Mail-Adresse, ssh-Benutzername oder gerrit-ID durchsuchen.
Im Allgemeinen ist es am besten, die Verwendung dieser Gerrit-Fähigkeit zu vermeiden, da jede Interaktion mit dem Patch - neue Patchsets, Kommentare, CI-Systemabstimmungen usw. - eine E-Mail-Benachrichtigung an jeden Reviewer auf dem Patch sendet.
Bemerkung
Wenn Sie einen Patch überprüfen, werden Sie automatisch zur Liste der Prüfer hinzugefügt.
Gerrit Web Editor¶
Es ist möglich, Ihren Patch im gerrit Webinterface zu bearbeiten und die Änderung zu veröffentlichen, ohne die Änderung lokal vorzunehmen. Dies wird im Allgemeinen nicht für größere Code-Updates empfohlen, da es nicht automatisch Ihren lokalen Arbeitszweig aktualisiert. In einigen Fällen, in denen der Patch grundsätzlich bereit ist, abgesehen von einem kleinen pep8-Fehler zusammenzuführen - Leerzeichen am Ende der Zeile, die eine Zeile umbrechen müssen, usw. - kann diese Gerrit-Funktion bequem sein, um eine schnelle Bearbeitung vorzunehmen und die Änderung zu veröffentlichen, ohne den gesamten Prozess von ‚git add‘, ‚git commit –amend‘, ‚git review‘ durchlaufen zu müssen.
Um den Gerrit Web Editor aufzurufen, klicken Sie auf das Symbol, das wie eine Bleistiftschrift auf Papier neben der Patch-Set-Nummer oben auf einer Gerrit Code Review-Seite für eine Datei aussieht.
Überprüfen von Änderungen¶
Die Überprüfung von Änderungen wird oft als Einstieg in ein Projekt vorgeschlagen. Egal, ob Sie sich so entscheiden, loszulegen oder nicht, es ist eine wichtige Gemeinschaftsaktivität. Siehe How to Review Changes the OpenStack Way für detaillierte Informationen darüber, wann welche Stimmen für eine Änderungsprüfung verwendet werden sollen.
Inline-Kommentare
Wenn Sie Fragen zur Art und Weise haben, wie etwas formuliert oder getan wird, oder wenn Sie ein anderes Problem gefunden haben, ist der einfachste Weg, den Autor des Patches wissen zu lassen, der Kommentar zu diesem Ort inline. Die Inline-Kommentare werden gemeinsam veröffentlicht, wenn Sie auf die Schaltfläche „Antworten“ klicken und Ihre Stimme zum Patchset hinzufügen.
Bemerkung
Bis Sie auf ‚Reply‘ klicken und über den Patch abstimmen, existieren alle Inline-Kommentare, die Sie gemacht haben, als Entwürfe.
+/- 1 & 0
Der grundlegende Satz von Werten, mit denen Mitwirkende bei einem Patch abstimmen müssen, ist: -1, 0 oder +1. Diese Werte entsprechen einem relativ einfachen System.
-1: Dieser Patch muss noch weiter bearbeitet werden, bevor er zusammengeführt werden kann. Ein -1 wird normalerweise angegeben, wenn der Prüfer ein Problem sieht, das behoben werden muss, bevor der Patch zusammengeführt werden kann. Die Themen, die der Autor behandeln muss, würden idealerweise Inline-Kommentare zu ihnen enthalten, es sei denn, es gibt ein größeres Problem. Wenn mit dem Gesamtansatz etwas nicht stimmt, können Sie bei der Abstimmung eine Gesamtkommentar abgeben, um Ihre Bedenken vorzubringen.
Bemerkung
Wenn Ihr Patch einen -1 erhält, ist es keine schlechte Nachricht, es bedeutet nur, dass Sie noch ein wenig mehr Arbeit erledigen mössen.
0: Kein Treffer. Dies ist die Standardpunktzahl bei der Antwort auf ein Patchset. Im Allgemeinen wird es als Stimme behalten, wenn jemand eine Frage über das Patchset hat oder noch keine vollständige Meinung über das Patchset hat - es erfordert mehr Zeit, Tests oder Untersuchungen.
+1: Sieht für mich gut aus, aber jemand anderes muss es genehmigen. Das bedeutet nicht, dass es nichts zu kommentieren gibt, nur dass es keine Probleme gibt, die das Zusammenführen des Patches blockieren würden. Sie können immer noch Kommentare zu pingeligen Dingen abgeben, die der Patch-Besitzer ansprechen kann, wenn andere Probleme mit dem Patch finden. Diese Kommentare können auch etwas sein, das in einem Followup-Patch im Gegensatz zu einem anderen Patchset behandelt werden sollte.
+/- 2 & +W
Die Hauptprüfer haben neben dem Basissatz zusätzliche Wahlmöglichkeiten. Wie die Grundmenge bilden die Zahlen ein einfaches Bedeutungssystem ab:
-2: Nicht mergen. Diese Partitur erscheint nicht oft, und wenn sie es tut, hat sie einen guten Grund:
Meistens ist eine Frist verstrichen und da bis zum Beginn der Entwicklung des neuen Releases keine Änderungen mehr akzeptiert werden, wird der Patch gehalten.
Es gibt ein Problem mit dem im Patch gewählten Ansatz, und er muss mit einer größeren Gruppe diskutiert werden, wahrscheinlich in einem Meeting.
Der eingereichte Patch ist ein Duplikat oder steht im Widerspruch zu einem anderen Patch.
Bemerkung
Nur die Person, die für die -2 gestimmt hat, kann die Stimme entfernen und sie bleibt bei allen neuen Patchsets bestehen.
+2: Sieht für mich gut aus (Kernprüfer). Abhängig vom Projektteam und dem Repository erfordert das Zusammenführen eines Patches mindestens eine +2 Stimme, wenn nicht sogar zwei +2 Stimmen.
+W: Genehmigt. Dieser Patch wird nun einer letzten Runde von Prüfungen unterzogen, bevor er in das Repository eingemischt wird.
Überprüfung Best Practices
Wenn Sie können, testen Sie den Code! In einigen Fällen haben Sie vielleicht keinen Zugriff auf die benötigte Hardware, aber im Allgemeinen sollten Sie in der Lage sein, die Änderungen zu testen oder sich den zuul build der Dokumentation anzusehen, so dass Sie mehr tun, als nur den Code oder die Änderung der Dokumentation zu betrachten.
Änderungen anderer auschecken¶
Es ist möglich, die Patches anderer Mitwirkender von Gerrit auszulesen und sogar Änderungen an ihnen vorzunehmen; jedoch sollten Sie alle Änderungen immer mit dem Mitwirkenden besprechen, bevor Sie mit der Arbeit an ihrem Patch beginnen.
git-review -d <change ID>
Die Änderungs-ID finden Sie auf der Web-Oberfläche von Gerrit:
Nach dem Auschecken des Patches werden Sie automatisch zu einem neuen Zweig gewechselt, an dem Sie Ihre Änderungen vornehmen können.
Cherry-picking¶
Wenn Ihr Commit von einer Änderung abhängt, die seit Beginn Ihrer Arbeit aktualisiert wurde, und Sie das neueste Patchset von dieser Änderung erhalten müssen, können Sie Ihre eigenen Änderungen darüber hinaus auswählen:
git review -x <change ID>
Die Änderungs-ID ist die gleiche wie im vorherigen Fall.
