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 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

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 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 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.

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, geschieht 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.

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.

Wichtige Optionen:

• -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: Teilt die Synchronisierung auf mehrere Threads auf, 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 Element manifest-server 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 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 Zweig der aktuelle ausgecheckte Zweig ist.
• Verwenden Sie repo upload --replace PROJECT, um den Editor für die Änderungssuche 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 dem Upload 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 kurz --cbr).

Bei zusammengehörigen Änderungen ist es sinnvoll, alle CLs im selben Thema zu belassen. Sie können beim Hochladen mit --topic=TOPIC einen Themennamen hinzufügen. Alternativ können Sie einfach -t übergeben, um den Themennamen mit dem Namen des lokalen Zweigs identisch zu setzen.

Unterschiede

repo diff [project-list]

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

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 stdin-, stdout- und sterr-Streams 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.

Pflaume

repo prune [project-list]

Entfernt (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.

Status

repo status [project-list]

Vergleicht den Arbeitsbaum mit dem Staging-Bereich (Index) und dem letzten Commit in diesem Zweig (HEAD) in jedem angegebenen Projekt. Zeigt für jede Datei, bei der es einen Unterschied zwischen diesen drei Zuständen 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 aufgelistet. 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 Commit-Status unterscheidet.

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

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} # 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 Zweig starten und ihn dann zusammenführen.

Git-Repository-Struktur

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