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 Tools zur Versionsverwaltung. Weitere Informationen zu Repo finden Sie in der Repo-README-Datei.

Die Verwendung von Repo hat folgende Form:

repo command options

Optionale Elemente werden in Klammern [] angezeigt. Viele Befehle verwenden beispielsweise project-list als Argument. Sie können project-list als Liste von Namen oder als Liste von Pfaden zu lokalen Quell verzeichnissen 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

Der folgende Befehl liefert 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 sehen 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 Verzeichnis .repo/ 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 finden Sie unter https://android.googlesource.com/platform/manifest.

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

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

Für alle verbleibenden Repo-Befehle muss das aktuelle Arbeitsverzeichnis entweder das übergeordnete Verzeichnis von .repo/ oder ein Unterverzeichnis des übergeordneten Verzeichnisses sein.

Synchronisieren

repo sync [project-list]

Lädt neue Änderungen herunter und aktualisiert die Arbeitsdateien in Ihrer lokalen Umgebung. Im Wesentlichen wird git fetch für alle Git-Repositories ausgeführt. 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 dem Befehl git clone. Alle Zweige im Remote-Repository werden in das lokale Projektverzeichnis kopiert.

• Wenn das Projekt bereits synchronisiert wurde, entspricht repo sync dem folgenden Befehl:

  git remote update
  git rebase origin/branch
  

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

  Hinweis: Wenn der Git-Rebase-Vorgang zu Merge-Konflikten führt, verwenden Sie die normalen Git-Befehle (z. B. git rebase --continue), um die Konflikte zu beheben.

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

Schlüsseloptionen:

• -c: Ruft nur den aktuellen Manifestzweig vom Server ab.
• -d: Setzt die angegebenen Projekte auf die Manifestversion zurück. Diese Option ist hilfreich, wenn sich das Projekt in einem Themenzweig befindet, die Manifestversion aber vorübergehend benötigt wird.
• -f: Fährt mit der Synchronisierung anderer Projekte fort, auch wenn die Synchronisierung eines Projekts fehlschlägt.
• -j threadcount: Verteilt die Synchronisierung auf mehrere Threads, um sie schneller abzuschließen. Achten Sie darauf, dass Ihr Computer nicht überlastet wird. Reservieren Sie einige CPU-Ressourcen für andere Aufgaben. Führen Sie zuerst nproc --all aus, um die Anzahl der verfügbaren CPUs zu ermitteln.
• -q: Führt den Befehl im Hintergrund aus, indem Statusmeldungen unterdrückt werden.
• -s: Synchronisiert mit einem bekannten guten Build, wie im manifest-server Element im aktuellen Manifest angegeben.

Weitere Optionen finden Sie unter repo help sync.

upload

repo upload [project-list]

Lädt Änderungen auf den Überprüfungsserver hoch. Für die angegebenen Projekte vergleicht Repo die lokalen Zweige mit den Remote-Zweigen, die bei der letzten Repo-Synchronisierung aktualisiert wurden. Repo fordert Sie auf, einen oder mehrere der Zweige 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 Upload-Autorisierung 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 zu einem einzigen Commit kombinieren möchten, verwenden Sie git rebase -i, bevor Sie den Upload ausführen.

Wenn Sie repo upload ohne Argumente ausführen, werden alle Projekte nach Änderungen durchsucht, die hochgeladen werden sollen.

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

• Prüfen Sie, ob der aktualisierte Zweig der aktuelle ausgecheckte Zweig ist.
• Verwenden Sie repo upload --replace PROJECT, um den Editor für übereinstimmende Ä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 look up 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-Zweig hochladen möchten, verwenden Sie das Flag --current-branch (oder --cbr).

Behalten Sie alle CLs für zusammengehörige Änderungen im selben Thema bei. Fügen Sie beim Hochladen mit --topic=TOPIC einen Themennamen hinzu oder übergeben Sie -t, um den Themennamen auf den lokalen Zweignamen festzulegen.

Unterschiede

repo diff [project-list]

Zeigt mit git diff ausstehende Änderungen zwischen dem Commit und dem Arbeitsverzeichnis 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.

So laden Sie beispielsweise die Änderung 23823 in Ihr platform/build Verzeichnis herunter:

repo download platform/build 23823

Wenn Sie repo sync ausführen, werden alle mit repo download abgerufenen Commits entfernt. Alternativ können Sie den Remote-Zweig mit git checkout m/main auschecken.

Hinweis: Es gibt Replikationsverzögerungen auf allen Servern weltweit. Daher gibt es eine leichte Verzögerung zwischen dem Zeitpunkt, zu dem eine Änderung in Gerrit im Web sichtbar ist, und dem Zeitpunkt, zu dem repo download die Änderung für alle Nutzer finden kann.

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 zur Verfügung gestellt:

• REPO_PROJECT ist auf den eindeutigen Namen des Projekts festgelegt.
• 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 Überarbeitung aus dem Manifest, übersetzt in einen lokalen Tracking-Zweig. Verwenden Sie diese Variable, wenn Sie die Manifestversion 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: Zeigt Projektheader vor der Ausgabe des angegebenen Befehls an. Dies wird erreicht, indem Pipes an die Streams „stdin“, „stdout“ und „stderr“ des Befehls gebunden und alle Ausgaben in einen kontinuierlichen Stream geleitet werden, der in einer einzigen Pager-Sitzung angezeigt wird.
• -v: Zeigt Nachrichten an, die der Befehl in „stderr“ schreibt.

prune

repo prune [project-list]

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

start

repo start branch-name [project-list]

Beginnt einen neuen Zweig für die Entwicklung, ausgehend von der im Manifest angegebenen Überarbeitung.

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

Das Argument project-list gibt an, welche Projekte an diesem Themenzweig beteiligt sind.

Hinweis: Ein Punkt ( . ) ist die Kurzform für das Projekt im aktuellen Arbeitsverzeichnis.

Status

repo status [project-list]

Vergleicht das Arbeitsverzeichnis mit dem Staging-Bereich (Index) und dem letzten Commit in diesem Zweig (HEAD) in jedem angegebenen Projekt. Zeigt für jede Datei eine Zusammenfassungszeile an, in der sich diese drei Status unterscheiden.

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

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

Buchstabe	Bedeutung	Beschreibung
-	Keine Änderung	Identisch in HEAD und Index
A	Hinzugefügt	Nicht in HEAD, aber im Index
M	Geändert	In HEAD, aber im Index geändert
D	Gelöscht	In HEAD, aber nicht im Index
R	Umbenannt	Nicht in HEAD, aber Pfad im Index geändert
C	Kopiert	Nicht in HEAD, aber im Index von einer anderen Datei kopiert
T	Modus geändert	Identischer Inhalt in HEAD und Index, aber Modus geändert
U	Nicht zusammengeführt	Konflikt zwischen HEAD und Index; Auflösung erforderlich

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

Buchstabe	Bedeutung	Beschreibung
-	Neu/unbekannt	Nicht im Index, aber im Arbeitsverzeichnis
m	Geändert	Im Index, im Arbeitsverzeichnis, aber geändert
d	Gelöscht	Im Index, aber nicht im Arbeitsverzeichnis

Repo-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} # 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. Um den Fehler zu beheben, prüfen Sie die Commit-ID, starten Sie einen neuen Zweig und führen Sie dann eine Zusammenführung durch.

Git-Repository-Struktur

Bei Android sind Git-Repositories (Projekte) nicht verschachtelt. Jedes Projekt ist einem bestimmten Verzeichnis in der Quellstruktur zugeordnet. Alle Unterverzeichnisse und Dateien in diesem Verzeichnis sind Teil desselben Projekts. Vermeiden Sie die Verwendung der Funktion git submodule von Repo für die Android-Entwicklung.