Repository-Befehlsreferenz

Repo ergänzt Git, indem es die Arbeit in mehreren Repositories vereinfacht. Eine Erläuterung der Beziehung zwischen Repo und Git finden Sie unter Tools zur Versionskontrolle. Weitere Informationen zu Repo finden Sie in der README-Datei für Repo.

Die Repo-Nutzung hat folgende Form:

repo command options

Optionale Elemente werden in eckigen Klammern [] angezeigt. Viele Befehle nehmen beispielsweise project-list als Argument an. 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

Hilfe zum Befehl repo. Detaillierte Informationen zu einem bestimmten Repo-Befehl erhalten Sie, wenn 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 sehen möchten, führen Sie Folgendes aus:

repo command --help

Beispiel:

repo init --help

init

repo init -u url [options]

Installiert das Repository im aktuellen Verzeichnis. Mit diesem Befehl wird ein Verzeichnis .repo/ mit Git-Repositories für den Repo-Quellcode und die standardmäßigen 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 standardmäßig default.xml verwendet.

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

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

Sync

repo sync [project-list]

Hier werden neue Änderungen heruntergeladen und die Arbeitsdateien in Ihrer lokalen Umgebung aktualisiert. Im Grunde 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 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.

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

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

Wichtige Optionen:

• -c: Nur den aktuellen Manifest-Branch vom Server abrufen.
• -d: Geben Sie für bestimmte Projekte die Manifestversion wieder zurück. Diese Option ist hilfreich, wenn sich das Projekt in einem Themenzweig befindet, die Manifestversion aber vorübergehend benötigt wird.
• -f: Mit der Synchronisierung anderer Projekte fortfahren, auch wenn die Synchronisierung eines Projekts fehlschlägt.
• threadcount: Die Synchronisierung auf mehrere Threads aufteilen, um sie schneller abzuschließen. Achten Sie darauf, dass Ihr Computer nicht überlastet wird. Lassen Sie etwas CPU-Leistung für andere Aufgaben frei. Führen Sie zuerst nproc --all aus, um die Anzahl der verfügbaren CPUs aufzurufen.
• -q: Sie können Statusmeldungen unterdrücken, um das Programm im Hintergrund auszuführen.
• -s: Synchronisieren Sie mit einem fehlerfreien Build, wie im aktuellen Manifest durch das Element manifest-server 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 Zweige mit den Remote-Zweigen, die bei der letzten Repo-Synchronisierung aktualisiert wurden. Sie werden aufgefordert, einen oder mehrere der Zweige auszuwählen, die noch nicht zur Überprüfung hochgeladen wurden.

Alle Commits in den ausgewählten Branches 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 seinen Server empfängt, wandelt er jeden Commit in eine Änderung um, damit Prüfer einen bestimmten Commit kommentieren können. Wenn Sie mehrere Checkpoint-Commits in 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, wird in allen Projekten nach Änderungen gesucht, die hochgeladen werden sollen.

Wenn Sie Änderungen nach dem Hochladen bearbeiten möchten, aktualisieren Sie Ihre lokalen Commits mit einem Tool wie git rebase -i oder git commit --amend. Wenn Sie alle Änderungen vorgenommen haben, gehen Sie so vor:

• Prüfen Sie, ob der aktualisierte Branch der aktuell ausgecheckte Branch ist.
• Drücken Sie die Taste repo upload --replace PROJECT, um den Editor für die Änderungsabgleiche 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 wird für die Änderungen ein zusätzlicher Patch festgelegt.

Wenn Sie nur den aktuell ausgecheckten Git-Zweig 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 halten. Sie können einen Themennamen beim Hochladen mit --topic=TOPIC hinzufügen. Du kannst auch einfach -t übergeben, um den Themanamen mit dem Namen der lokalen Branche zu übereinstimmen.

diff

repo diff [project-list]

Mit git diff werden ausstehende Änderungen zwischen dem Commit und dem Arbeitsbaum angezeigt.

Herunterladen

repo download target change

Die angegebene Änderung wird aus dem Überprüfungssystem heruntergeladen und im lokalen Arbeitsverzeichnis Ihres Projekts verfügbar gemacht.

So laden Sie beispielsweise change 23823 in das Verzeichnis platform/build herunter:

repo download platform/build 23823

Wenn Sie repo sync ausführen, werden alle Commits entfernt, die mit repo download abgerufen wurden. Sie können den Remote-Branch auch mit git checkout m/main auschecken.

Hinweis: Aufgrund von Replikationsverzögerungen auf allen Servern weltweit gibt es eine kurze Verzögerung bei der Spiegelung, d. h. zwischen dem Zeitpunkt, zu dem eine Änderung im Web in Gerrit sichtbar ist, und dem Zeitpunkt, zu dem sie in repo download für alle Nutzer zu sehen ist.

forall

repo forall [project-list] -c command

Führt den angegebenen Shell-Befehl in jedem Projekt aus. repo forall stellt die folgenden zusätzlichen Umgebungsvariablen bereit:

• REPO_PROJECT ist auf den eindeutigen Namen des Projekts festgelegt.
• REPO_PATH ist der Pfad relativ zum Stamm des Clients.
• REPO_REMOTE ist der Name des Remotesystems aus dem Manifest.
• REPO_LREV ist der Name der Version aus dem Manifest, der in einen lokalen Tracking-Branch übersetzt wurde. Verwenden Sie diese Variable, wenn Sie die Manifestversion an einen lokal ausgeführten Git-Befehl übergeben müssen.
• REPO_RREV ist der Name der Version aus dem Manifest, genau so, wie er im Manifest steht.

Optionen:

• -c: Befehl und Argumente, die ausgeführt werden sollen. Der Befehl wird über /bin/sh ausgewertet und alle nachfolgenden Argumente werden als Positionsparameter der Shell übergeben.
• -p: Projektüberschriften vor der Ausgabe des angegebenen Befehls anzeigen. Dazu werden Pipes an die stdin-, stdout- und sterr-Streams des Befehls gebunden und die gesamte Ausgabe in einen kontinuierlichen Stream geleitet, der in einer einzelnen Pager-Sitzung angezeigt wird.
• -v: Zeigt Meldungen 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]

Startet einen neuen Entwicklungszweig, ausgehend von der im Manifest angegebenen Version.

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

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

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

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. Für jede Datei, bei der ein Unterschied zwischen diesen drei Status besteht, wird eine Zusammenfassungszeile angezeigt.

Wenn Sie nur den Status des aktuellen Branches 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, inwiefern sich der Staging-Bereich vom letzten Commit-Status unterscheidet.

Letter	Bedeutung	Beschreibung
-	Keine Änderung	In HEAD und Index identisch
A	Hinzugefügt	Nicht im HEAD-Element, sondern im Index
M	Geändert	In HEAD, im Index geändert
D	Gelöscht	Im HEAD-Element, nicht im Index
R	Umbenannt	Nicht im HEAD-Element, Pfad im Index geändert
C	Kopiert	Nicht im HEAD, aus einem anderen im Index kopiert
T	Modus geändert	Selbe Inhalte in HEAD und Index, Modus geändert
U	Nicht zusammengeführt	Konflikt zwischen HEAD und Index; Lösung erforderlich

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

Letter	Bedeutung	Beschreibung
-	Neu/unbekannt	Nicht im Index, im Arbeitsbaum
m	Geändert	Im Index, im Arbeitsbaum, geändert
t	Gelöscht	Im Index, nicht im Arbeitsbaum

Fehler im Repository behandeln

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. Sie können die Commit-ID prüfen, einen neuen Branch starten und ihn dann zusammenführen.