Repository-Befehlsreferenz

Repository ergänzt Git durch die Vereinfachung der Arbeit über mehrere Repositories hinweg. 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 Verwendung des Repositorys sieht so aus:

repo command options

Optionale Elemente werden in Klammern [] angezeigt. Viele Befehle verwenden z. B. project-list als Argument. Sie können project-list angeben als Liste von Namen oder als Liste mit Pfaden zu lokalen Quellverzeichnissen für die Projekten:

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 Einen bestimmten Repository-Befehl, bei dem ein Befehl als Option angegeben wird:

repo help command

Der folgende Befehl liefert beispielsweise eine Beschreibung und eine Liste von Optionen für den Befehl init:

repo help init

Oder führen Sie folgenden Befehl aus, um nur die Liste der verfügbaren Optionen für einen Befehl anzuzeigen:

repo command --help

Hier einige Beispiele:

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 der Standardwert default.xml verwendet.

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

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 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; werden alle Zweige im Remote-Repository in das lokale Projektverzeichnis.

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

  git remote update
  git rebase origin/branch
  

  Dabei ist branch die aktuelle Filiale in der Region, in der Sie bezahlt haben Projektverzeichnis. Wenn der lokale Branch keinen Branch im Remote-Repository verfolgt, erfolgt keine Synchronisierung für das Projekt.

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: Ruft nur den aktuellen Manifestzweig vom Server ab.
• -d: Angegebene Projekte zurück zur Manifestversion wechseln. Diese Option ist hilfreich, wenn sich das Projekt in einem Themenzweig befindet, aber die Manifestversion vorübergehend benötigt wird.
• -f: Mit der Synchronisierung anderer Projekte fortfahren, auch wenn die Synchronisierung eines Projekts fehlschlägt.
• threadcount: Synchronisierung auf Threads aufteilen für schnellere Ausführung. Achten Sie darauf, dass Ihr Computer nicht überlastet wird. Lassen Sie etwas CPU-Leistung für andere Aufgaben frei. Führen Sie zuerst den folgenden Befehl aus, um die Anzahl der verfügbaren CPUs zu sehen: nproc --all
• -q: Sie können Statusmeldungen unterdrücken, um das Programm im Hintergrund auszuführen.
• -s: Mit einem als fehlerfrei bekannten Build synchronisieren, wie durch das Element manifest-server angegeben im aktuellen Manifest.

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

Upload-

repo upload [project-list]

Lädt Änderungen auf den Rezensionsserver hoch. Für die angegebenen Projekte vergleicht das Repository Die lokalen Zweige zu den Remote-Zweigen, die während der letzten Repository-Synchronisierung aktualisiert wurden. Das Repository fordert Sie auf, einen oder mehrere Zweige auszuwählen, die noch nicht wurde zur Überprüfung hochgeladen.

Alle Commits für die ausgewählten Zweige werden dann über ein HTTPS-Verbindung. Sie müssen ein HTTPS-Passwort konfigurieren, um die Uploadautorisierung zu aktivieren. So erstellen Sie ein neues Nutzername/Passwort-Paar für die Verwendung über HTTPS: besuchen Sie die Passwortgenerator

Wenn Gerrit die Objektdaten über seinen Server empfängt, wandelt es jeden Commit in eine Änderung um, damit Prüfer einen bestimmten Commit kommentieren können. Verwenden Sie git rebase -i, um mehrere Checkpoint-Commits zu einem einzigen Commit zu kombinieren. bevor Sie den Upload ausführen.

Wenn Sie repo upload ohne Argumente ausführen, wird in allen Projekten nach hochladen können.

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. Nachdem Ihre Änderungen Abgeschlossen:

• Prüfen Sie, ob der aktualisierte Branch der aktuell ausgecheckte Branch ist.
• Verwenden Sie repo upload --replace PROJECT, um den Editor für Ä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).

Unterschied

repo diff [project-list]

Zeigt ausstehende Änderungen zwischen dem Commit und der Arbeitsstruktur mithilfe von git diff

Herunterladen

repo download target change

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

Um beispielsweise 23823 zu Ihrem Verzeichnis platform/build:

repo download platform/build 23823

Durch die Ausführung von repo sync werden alle mit repo download abgerufenen Commits entfernt. Oder Sie können den Remote-Zweig mit git checkout m/main prüfen.

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 eine 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 hier angegeben im Manifest.

Optionen:

• -c: Befehl und Argumente, die ausgeführt werden sollen. Der Befehl wird über /bin/sh und alle Argumente, nachdem sie als Shell-Positionsargument übergeben wurden Parameter.
• -p: Projektüberschriften vor der Ausgabe des angegebenen Befehls anzeigen. Dies ist durch Binden von Pipes an die Streams stdin, stdout und sterr des Befehls und Leiten der gesamten Ausgabe an einen kontinuierlichen Stream, der auf einem einzigen Pager angezeigt wird Sitzung.
• -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 Zweig für die Entwicklung, beginnend mit der im Manifests.

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

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

Status

repo status [project-list]

Vergleicht den Arbeitsbaum mit dem Staging-Bereich (Index) und dem letzten Commit. auf diesem Zweig (HEAD) in jedem angegebenen Projekt. Zeigt eine Zusammenfassungszeile für bei denen es einen Unterschied zwischen diesen drei Zuständen gibt.

Wenn Sie nur den Status des aktuellen Branches sehen möchten, führen Sie repo status . aus. Status sind 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 Stagingbereich vom letzten Commit-Status unterscheidet.

Letter	Bedeutung	Beschreibung
-	Keine Änderung	Gleich in HEAD und Index
A	Hinzugefügt	Nicht in HEAD, 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-Element, kopiert von einem anderen im Index
T	Modus geändert	Gleicher Inhalt in HEAD und Index, Modus geändert
U	Nicht zusammengeführt	Konflikt zwischen HEAD und Index Auflö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

Repository-Fehler verarbeiten

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 der Commit-ID, starten Sie einen neuen Zweig und führen Sie ihn zusammen.