git-review - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-rezension — Änderungen zur Überprüfung an Gerrit senden

ZUSAMMENFASSUNG

git-rezension [-r entfernt] [-uv] -d Übernehmen [Filiale]
git-rezension [-r entfernt] [-uv] -x Übernehmen [Filiale]
git-rezension [-r entfernt] [-uv] -N Übernehmen [Filiale]
git-rezension [-r entfernt] [-uv] -X Übernehmen [Filiale]
git-rezension [-r entfernt] [-uv] -m PS-Bereich ändern [Filiale]
git-rezension [-r entfernt] [-fnuv] -s [Filiale]
git-rezension [-fnuvDRT] [-r entfernt] [-t Thema] [--Rezensenten Kritiker ...] [Filiale]
git-rezension -l
git-rezension --Version

BESCHREIBUNG

git-rezension automatisiert und rationalisiert einige der Aufgaben, die mit der Übermittlung lokaler
Änderungen an einen Gerrit-Server zur Überprüfung. Es soll das Verständnis erleichtern
Gerrit, insbesondere für Benutzer, die kürzlich von einer anderen Versionskontrolle auf Git umgestiegen sind
System funktionieren.

Übernehmen kann sein Nummer wechseln wie erhalten mit --aufführen Option, oder es kann sein
Änderungsnummer, Patchsetnummer zum Abrufen des genauen Patchsets aus der Änderung. In diesem Fall lokal
Der Zweigname hat das Suffix -patch[patchsetNumber].

Die folgenden Optionen sind verfügbar:

-d Übernehmen , --download=Übernehmen
Herunterladen Übernehmen von Gerrit in eine lokale Filiale. Die Filiale wird nach dem benannt
Patch-Autor und den Namen eines Themas. Wenn die lokale Filiale bereits existiert, wird sie
Versuchen Sie, mit dem neuesten Patchset für diese Änderung zu aktualisieren.

-x Übernehmen , --cherrypick=Übernehmen
Jetzt bewerben Übernehmen von Gerrit und verpflichten sich in den aktuellen Ortszweig ("Cherry Pick").
Es wird kein zusätzlicher Zweig erstellt.

Dadurch ist es möglich, eine Änderung zu überprüfen, ohne dafür eine lokale Verzweigung zu erstellen. Auf
Achtung: Wenn Sie nicht aufpassen, kann dies leicht zu
zusätzliche Patch-Sets für abhängige Änderungen. Auch wenn der aktuelle Zweig . ist
unterschiedlich genug, wird die Änderung möglicherweise überhaupt nicht angewendet oder führt zu Zusammenführungskonflikten, die
müssen von Hand gelöst werden.

-N Übernehmen , --cherrypickonly=Übernehmen
Jetzt bewerben Übernehmen von Gerrit in das aktuelle Arbeitsverzeichnis, füge es dem Staging hinzu
area ("git index"), aber nicht festschreiben.

Dadurch ist es möglich, eine Änderung zu überprüfen, ohne dafür einen lokalen Commit zu erstellen.
Nützlich, wenn Sie mehrere Commits zu einem zusammenführen möchten, für das eingereicht wird
überprüfen.

Wenn der aktuelle Zweig unterschiedlich genug ist, wird die Änderung möglicherweise überhaupt nicht angewendet oder
Zusammenführungskonflikte erzeugen, die von Hand gelöst werden müssen.

-X Übernehmen , --cherrypickindicate=Übernehmen
Jetzt bewerben Übernehmen von Gerrit und verpflichten sich in den aktuellen Ortsverband ("Cherry Pick"),
gibt an, aus welchem ​​Commit diese Änderung ausgewählt wurde.

Dadurch ist es möglich, eine Änderung für einen anderen Zweig erneut zu überprüfen, ohne zu erstellen
eine örtliche Filiale dafür.

Wenn der aktuelle Zweig unterschiedlich genug ist, wird die Änderung möglicherweise überhaupt nicht angewendet oder
Zusammenführungskonflikte erzeugen, die von Hand gelöst werden müssen.

-m PS-Bereich ändern, --vergleichen=PS-Bereich ändern
Laden Sie die angegebenen Patchsets herunter für Übernehmen von Gerrit, rebasiere sowohl auf Meister als auch auf
Anzeigeunterschiede (git-diff).

PS-Bereich ändern kann angegeben werden als
Änderungsnummer,altePatchSetNummer[-neuePatchSetNummer]

altePatchSetNummer ist obligatorisch, und wenn neuePatchSetNummer ist nicht angegeben, die
das neueste Patchset wird verwendet.

So können Sie ganz einfach vergleichen, was sich seit dem letzten Mal geändert hat
die vorgeschlagene Änderung überprüft.

Wenn der Master-Zweig unterschiedlich genug ist, kann das Rebase zu Zusammenführungskonflikten führen.
In diesem Fall wird das Rebasing abgebrochen und ein Unterschied für nicht rebasiert angezeigt
Geäst. Sie können auch verwenden --no-rebase (-R), um das Rebasing immer zu überspringen.

-f, --beenden
Schließen Sie den lokalen Branch und wechseln Sie bei Erfolg zurück in den Ziel-Branch
Einreichung.

-n, --Probelauf
Führen Sie keine Befehle aus, die direkte Auswirkungen haben. Drucken Sie sie stattdessen aus.

-r entfernt, --remote=entfernt
Git-Fernbedienung für Gerrit.

-s, --erstellen
Führen Sie einfach die Repository-Setup-Befehle aus, aber senden Sie nichts.

-t Thema, --topic=Thema
Legt das Zielthema für diese Änderung auf dem Gerrit-Server fest. Wenn nicht angegeben, ein Fehler
Nummer aus der Commit-Zusammenfassung wird verwendet. Alternativ der lokale Filialname
wird verwendet, wenn es sich von der Remote-Zweigstelle unterscheidet.

-T, - kein Thema
Bewertung ohne Thema abgeben.

--Rezensenten Kritiker ...
Abonnieren Sie einen oder mehrere Reviewer für die hochgeladenen Patch-Sets. Gutachter sollten sein
von Gerrit identifizierbar (in der Regel verwenden Sie den Gerrit-Benutzernamen oder die E-Mail-Adresse).

-u, --aktualisieren
Überspringen Sie zwischengespeicherte lokale Kopien und erzwingen Sie Updates von Netzwerkressourcen.

-l, --aufführen
Listen Sie die verfügbaren Bewertungen auf dem Gerrit-Server für dieses Projekt auf.

-y, --Ja
Geben Sie an, dass Sie tatsächlich verstehen, wenn Sie mehr als einen Patch einreichen.

-v - ausführlich
Aktiviert eine ausführlichere Ausgabe.

-D, --Luftzug
Bewertung als Entwurf einreichen. Erfordert Gerrit 2.3 oder neuer.

-R, --no-rebase
Führen Sie keine automatische Rebase durch, bevor Sie die Änderung an Gerrit senden.

Wenn Sie eine Änderung zur Überprüfung einreichen, möchten Sie normalerweise, dass sie auf dem Tipp basiert
des vorgelagerten Zweigs, um mögliche Konflikte zu vermeiden. Beim Ändern einer Änderung und
Beim Rebasing des neuen Patchsets zeigt die Gerrit-Weboberfläche einen Unterschied zwischen
die beiden Patchsets, die alle Commits dazwischen enthalten. Das kann viele verwirren
Rezensenten, die einen viel einfacheren Unterschied erwarten würden.

Kann auch verwendet werden für --vergleichen um das automatische Rebase von abgerufenen Bewertungen zu überspringen.

--nachverfolgen
Wählen Sie den Branch aus, für den die Änderung eingereicht werden soll (und bei einer Rebasierung für die Rebase)
von der zu verfolgenden Filiale (wenn eine Filiale verfolgt wird) und stellen Sie die Verfolgung ein
Branch beim Herunterladen einer Änderung, um auf den Remote- und Branch zu verweisen, gegen den
Patches sind einzureichen. Siehe gitreview.track-Konfiguration.

--keine Spur
Ignorieren Sie jeden Branch, der vom aktuellen Branch verfolgt wird, und überschreiben Sie gitreview.track.
Diese Option wird durch die Angabe eines bestimmten Zweignamens in der Befehlszeile impliziert.

--Version
Drucken Sie die Versionsnummer und beenden Sie.

CONFIGURATION

Dieses Dienstprogramm kann durch Hinzufügen von Einträgen zur Git-Konfiguration konfiguriert werden.

Die folgenden Konfigurationsschlüssel werden unterstützt:

gitreview.Benutzername
Standardbenutzername für den Zugriff auf das Repository. Falls nicht im Git . angegeben
Konfiguration, Git remote oder .gitrezension Datei, wird der Benutzer aufgefordert,
den Benutzernamen angeben.

Beispieleintrag im .gitconfig Datei:

[GitRezension]
Benutzername =meingerrituser

gitreview.schema
Diese Einstellung bestimmt das Standardschema (ssh/http/https) von gerrit remote

gitreview.host
Diese Einstellung bestimmt den Standard-Hostnamen von gerrit remote

gitreview.port
Diese Einstellung bestimmt den Standardport von gerrit remote

gitreview.project
Diese Einstellung bestimmt den Standardnamen von gerrit git repo

gitreview.remote
Diese Einstellung bestimmt den Standardnamen für gerrit remote

gitreview.branch
Diese Einstellung bestimmt den Standardzweig

gitreview.track
Legt fest, ob der aktuell verfolgte Zweig (falls vorhanden) und der
Branch, für den das Changeset an Gerrit übermittelt wurde (falls vorhanden
genau einen solchen Branch) an defaultremote und defaultbranch zum Einreichen
und Rebasierung gegen. Wenn der lokale Topic-Branch einen Remote-Branch verfolgt,
die Remote und Branch, die der lokale Topic-Branch verfolgt, sollten verwendet werden
für Submit- und Rebase-Vorgänge anstelle von defaultremote und
Standardzweig.

Erstellt beim Herunterladen eines Patches den lokalen Zweig, um die entsprechenden zu verfolgen
remote und branch, um beim Senden standardmäßig diesen Branch auszuwählen
Änderungen an diesem Changeset.

Es sollte ein Wert von 'true' oder 'false' angegeben werden.

true Bevorzuge den aktuell verfolgten Zweig (falls vorhanden) - äquivalent zu
Einstellung --nachverfolgen beim Einreichen von Änderungen.

false Tracking-Zweige ignorieren - entspricht Einstellung --keine Spur (Das
Standard) oder beim Senden einen expliziten Zweignamen angeben
Änderungen. Dies ist der Standardwert, es sei denn, er wird von . überschrieben
.gitrezension Datei und wird durch die Bereitstellung eines bestimmten Zweigs impliziert
Namen in der Befehlszeile.

gitreview.rebase
Diese Einstellung legt fest, ob eingereichte Änderungen auf die
neueste Stand der Branche.

Es sollte ein Wert von 'true' oder 'false' angegeben werden.

false Änderungen beim Senden nicht neu basieren - entspricht Einstellung -R wann
Änderungen einreichen.

true Änderungen beim Senden umbasieren. Dies ist der Standardwert, es sei denn
überschrieben von .gitrezension Datei.

Diese Einstellung hat Vorrang vor der Repository-spezifischen Konfiguration im
.gitrezension Datei.

color.review Ob ANSI-Escape-Sequenzen verwendet werden sollen, um der Ausgabe Farbe hinzuzufügen, die von . angezeigt wird
dieser Befehl. Der Standardwert wird von color.ui bestimmt.

auto oder true Wenn Sie möchten, dass die Ausgabe beim Schreiben in das Terminal Farbe verwendet
(Standard mit Git 1.8.4 und neuer).

immer Wenn Sie möchten, dass alle Ausgaben Farbe verwenden

nie oder falsch
Wenn Sie keine Farbe für eine Ausgabe verwenden möchten. (Standard mit Git
älter als 1.8.4)

git-rezension fragt das Git-Anmeldesystem nach Gerrit-Benutzer/Passwort bei der Authentifizierung ab
über http(s) fehlgeschlagen. Im Gegensatz zu git, git-rezension beharrt gerrit user/password nicht in git
Anmeldesystem für Sicherheitszwecke und die Konfiguration des Git-Anmeldesystems bleibt unter
Verantwortung des Benutzers.

Verwenden Sie git-review online mit den onworks.net-Diensten