Repo-Befehlsreferenz

Repo ergänzt Git, indem es die Arbeit mit mehreren Repositories vereinfacht. Eine Erläuterung der Beziehung zwischen Repo und Git finden Sie unter Versionsverwaltungstools. Weitere Informationen zu Repo finden Sie in der README-Datei zu Repo.

Die Verwendung von Repositories hat folgende Form:

repo command options

Optionale Elemente werden in eckigen Klammern [] angegeben. Viele Befehle verwenden beispielsweise project-list als Argument. Sie können project-list als Liste mit Namen oder als Liste mit Pfaden zu lokalen Quellverzeichnissen für die Projekte angeben:

repo sync [project0 project1 ... projectn]
repo sync [/path/to/project0 ... /path/to/projectn]

Hilfe

repo help

Bietet Hilfe zum Befehl repo. Sie können detaillierte Informationen zu einem bestimmten Repo-Befehl aufrufen, indem Sie einen Befehl als Option angeben:

repo help command

Mit dem folgenden Befehl erhalten Sie beispielsweise eine Beschreibung und eine Liste der Optionen für den Befehl init:

repo help init

Wenn Sie nur die Liste der verfügbaren Optionen für einen Befehl aufrufen möchten, führen Sie Folgendes aus:

repo command --help

Beispiel:

repo init --help

init

repo init -u url [options]

Installiert Repo im aktuellen Verzeichnis. Mit diesem Befehl wird ein .repo/-Verzeichnis mit Git-Repositories für den Repo-Quellcode und die Standard-Android-Manifestdateien erstellt.

Optionen:

• -u: Geben Sie eine URL an, von der ein Manifest-Repository abgerufen werden soll. Das gemeinsame Manifest befindet sich unter https://android.googlesource.com/platform/manifest.

• -m: Wählen Sie eine Manifestdatei im Repository aus. Wenn kein Manifestname ausgewählt ist, wird der Standardwert default.xml verwendet.

• -b: Geben Sie eine Überarbeitung an, d. h. eine bestimmte manifest-branch.

Sync

repo sync [project-list]

Lädt neue Änderungen herunter und aktualisiert die Arbeitsdateien in Ihrer lokalen Umgebung. Dies entspricht im Wesentlichen git fetch für alle Git-Repositories. Wenn Sie repo sync ohne Argumente ausführen, werden die Dateien für alle Projekte synchronisiert.

Wenn Sie repo sync ausführen, passiert Folgendes:

• Wenn das Projekt noch nie synchronisiert wurde, entspricht repo sync git clone. Alle Branches im Remote-Repository werden in das lokale Projektverzeichnis kopiert.

• Wenn das Projekt bereits synchronisiert wurde, entspricht repo sync Folgendem:

  git remote update
  git rebase origin/branch
  

  Dabei ist branch der aktuell ausgecheckte Branch im lokalen Projektverzeichnis. Wenn der lokale Branch keinen Branch im Remote-Repository verfolgt, erfolgt keine Synchronisierung für das Projekt.

Nach erfolgreicher Ausführung von repo sync ist der Code in den angegebenen Projekten auf dem neuesten Stand und mit dem Code im Remote-Repository synchronisiert.

Wichtige Optionen:

• -c: Nur den aktuellen Manifest-Branch vom Server abrufen.
• -d: Die angegebenen Projekte werden wieder auf die Manifestrevision umgestellt. Diese Option ist hilfreich, wenn sich das Projekt in einem Themenzweig befindet, die Manifestrevision jedoch vorübergehend benötigt wird.
• -f: Synchronisieren Sie andere Projekte auch dann, wenn die Synchronisierung eines Projekts fehlschlägt.
• -j threadcount: Die Synchronisierung wird auf mehrere Threads aufgeteilt, um sie zu beschleunigen. Achten Sie darauf, dass Ihr Computer nicht überlastet wird. Lassen Sie etwas CPU für andere Aufgaben reserviert. Führen Sie zuerst nproc --all aus, um die Anzahl der verfügbaren CPUs zu sehen.
• -q: Führen Sie den Befehl im Hintergrund aus, indem Sie Statusmeldungen unterdrücken.
• -s: Synchronisieren mit einem bekannten guten Build, wie im manifest-server-Element im aktuellen Manifest angegeben.

Führen Sie repo help sync aus, um weitere Optionen anzuzeigen.

Upload-

repo upload [project-list]

Lädt Änderungen auf den Überprüfungsserver hoch. Für die angegebenen Projekte vergleicht Repo die lokalen Branches mit den Remote-Branches, die bei der letzten Repo-Synchronisierung aktualisiert wurden. Repo fordert Sie auf, einen oder mehrere der Branches auszuwählen, die noch nicht zur Überprüfung hochgeladen wurden.

Alle Commits in den ausgewählten Zweigen werden dann über eine HTTPS-Verbindung an Gerrit übertragen. Sie müssen ein HTTPS-Passwort konfigurieren, um die Uploadautorisierung zu aktivieren. Wenn Sie ein neues Nutzername/Passwort-Paar für die Verwendung über HTTPS generieren möchten, rufen Sie den Passwortgenerator auf.

Wenn Gerrit die Objektdaten über den Server empfängt, wird jeder Commit in eine Änderung umgewandelt, damit Prüfer einen bestimmten Commit kommentieren können. Wenn Sie mehrere Checkpoint-Commits in einem einzigen Commit zusammenfassen möchten, verwenden Sie git rebase -i, bevor Sie den Upload ausführen.

Wenn Sie repo upload ohne Argumente ausführen, wird in allen Projekten nach Änderungen gesucht, die hochgeladen werden müssen.

Wenn Sie Änderungen nach dem Hochladen bearbeiten möchten, verwenden Sie ein Tool wie git rebase -i oder git commit --amend, um Ihre lokalen Commits zu aktualisieren. Nachdem Sie alle Änderungen vorgenommen haben:

• Prüfen Sie, ob der aktualisierte Branch der aktuell ausgecheckte Branch ist.
• Verwenden Sie repo upload --replace PROJECT, um den Editor für den Abgleich von Änderungen zu öffnen.

• Geben Sie für jeden Commit in der Reihe die Gerrit-Änderungs-ID in die Klammern ein:

  # Replacing from branch foo
  [ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
  [ 2829 ] ec18b4ba Update proto client to support patch set replacements
  # Insert change numbers in the brackets to add a new patch set.
  # To create a new change record, leave the brackets empty.
  

Nach Abschluss des Uploads haben die Änderungen ein zusätzliches Patch-Set.

Wenn Sie nur den aktuell ausgecheckten Git-Branch hochladen möchten, verwenden Sie das Flag --current-branch (oder kurz --cbr).

Bei zusammenhängenden Änderungen ist es sinnvoll, alle CLs im selben Thema zu belassen. Sie können beim Hochladen mit --topic=TOPIC einen Themennamen hinzufügen. Oder übergeben Sie einfach -t, um den Themennamen auf den Namen des lokalen Zweigs festzulegen.

Unterschied

repo diff [project-list]

Zeigt ausstehende Änderungen zwischen dem Commit und dem Arbeitsbaum mit git diff an.

Herunterladen

repo download target change

Lädt die angegebene Änderung aus dem Überprüfungssystem herunter und stellt sie im lokalen Arbeitsverzeichnis Ihres Projekts zur Verfügung.

Wenn Sie beispielsweise Änderung 23823 in Ihr platform/build-Verzeichnis herunterladen möchten:

repo download platform/build 23823

Durch Ausführen von repo sync werden alle mit repo download abgerufenen Commits entfernt. Alternativ können Sie den Remote-Branch mit git checkout m/main auschecken.

forall

repo forall [project-list] -c command

Führt den angegebenen Shell-Befehl in jedem Projekt aus. Die folgenden zusätzlichen Umgebungsvariablen werden von repo forall bereitgestellt:

• REPO_PROJECT ist der eindeutige Name des Projekts.
• REPO_PATH ist der Pfad relativ zum Stammverzeichnis des Clients.
• REPO_REMOTE ist der Name des Remotesystems aus dem Manifest.
• REPO_LREV ist der Name der Revision aus dem Manifest, übersetzt in einen lokalen Tracking-Branch. Verwenden Sie diese Variable, wenn Sie die Manifestrevision an einen lokal ausgeführten Git-Befehl übergeben müssen.
• REPO_RREV ist der Name der Überarbeitung aus dem Manifest, genau wie im Manifest geschrieben.

Optionen:

• -c: Befehl und Argumente, die ausgeführt werden sollen. Der Befehl wird über /bin/sh ausgewertet und alle Argumente danach werden als Shell-Positionsparameter übergeben.
• -p: Projektüberschriften vor der Ausgabe des angegebenen Befehls anzeigen. Dies wird erreicht, indem Pipes an die stdin-, stdout- und sterr-Streams des Befehls gebunden werden und die gesamte Ausgabe in einen kontinuierlichen Stream geleitet wird, der in einer einzelnen Pager-Sitzung angezeigt wird.
• -v: Zeigt Nachrichten an, die vom Befehl in „stderr“ geschrieben werden.

entfernen

repo prune [project-list]

Löscht Themen, die bereits zusammengeführt wurden.

start

repo start branch-name [project-list]

Beginnt einen neuen Branch für die Entwicklung, ausgehend von der im Manifest angegebenen Revision.

Das Argument BRANCH_NAME enthält eine kurze Beschreibung der Änderung, die Sie an den Projekten vornehmen möchten. Wenn Sie ihn nicht kennen, verwenden Sie den Namen default.

Mit dem Argument project-list wird angegeben, welche Projekte an diesem Themenzweig beteiligt sind.

Status

repo status [project-list]

Vergleicht den Arbeitsbaum mit dem Staging-Bereich (Index) und dem letzten Commit in diesem Branch (HEAD) in jedem angegebenen Projekt. Zeigt für jede Datei, in der es einen Unterschied zwischen diesen drei Status gibt, eine Zusammenfassungszeile an.

Wenn Sie nur den Status des aktuellen Zweigs sehen möchten, führen Sie repo status . aus. Die Statusinformationen werden nach Projekt aufgeführt. Für jede Datei im Projekt wird ein zweistelliger Code verwendet.

In der ersten Spalte gibt ein Großbuchstabe an, wie sich der Staging-Bereich vom letzten committeten Status unterscheidet.

In der zweiten Spalte gibt ein Kleinbuchstabe an, wie sich das Arbeitsverzeichnis vom Index unterscheidet.

Repository-Fehler beheben

git commit -a # Commit local changes first so they aren't lost.
repo start branch-name # Start the branch
git reset --hard HEAD@{1} # And reset the branch so that it matches the commit before repo start
repo upload .

Der Fehler repo: error: no branches ready for upload wird angezeigt, wenn der Befehl repo start nicht zu Beginn der Sitzung ausgeführt wurde. Zur Wiederherstellung können Sie die Commit-ID prüfen, einen neuen Branch starten und ihn dann zusammenführen.