Repository ergänzt Git durch die Vereinfachung der Arbeit über mehrere Repositories hinweg. Eine Erläuterung der Beziehung zwischen Repository und Git finden Sie unter Versionsverwaltungstools. Weitere Informationen zum Repository finden Sie in der README-Datei für das Repository.
Die Verwendung des Repositorys sieht so aus:
repo command options
Optionale Elemente werden in Klammern [] angezeigt. 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 Repository-Befehl ansehen und einen Befehl als Option angeben:
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
Beispiel:
repo init --help
init
repo init -u url [options]
Installiert das Repository im aktuellen Verzeichnis. Mit diesem Befehl wird ein .repo/
-Verzeichnis mit Git-Repositories für den Repository-Quellcode und den Android-Standardmanifestdateien erstellt.
Optionen:
-u
: Geben Sie eine URL an, von der ein Manifest-Repository abgerufen werden soll. Das allgemeine Manifest finden Sie unterhttps://android.googlesource.com/platform/manifest
.-m
: Wählen Sie eine Manifestdatei im Repository aus. Wenn kein Manifestname ausgewählt ist, ist der Standardwertdefault.xml
.-b
: Gibt eine Überarbeitung an, also eine bestimmte manifest-branch.
Sync
repo sync [project-list]
Es lädt neue Änderungen herunter und aktualisiert die Arbeitsdateien in Ihrer lokalen Umgebung. Im Wesentlichen wird git fetch
in allen 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 Zweige im Remote-Repository werden in das lokale Projektverzeichnis kopiert.Wenn das Projekt bereits zuvor synchronisiert wurde, entspricht
repo sync
der folgenden Bedingung:git remote update git rebase origin/branch
Dabei ist branch der aktuell ausgecheckte Zweig im lokalen Projektverzeichnis. Wenn der lokale Zweig einen Zweig im Remote-Repository nicht verfolgt, findet keine Synchronisierung für das Projekt statt.
Nachdem repo sync
erfolgreich ausgeführt wurde, 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
: Angegebene Projekte zurück zur Manifestversion wechseln. Diese Option ist hilfreich, wenn sich das Projekt in einem Themenzweig befindet, die Manifestüberarbeitung aber vorübergehend benötigt wird.-f
: Die Synchronisierung anderer Projekte wird auch dann fortgesetzt, wenn die Synchronisierung eines Projekts fehlschlägt.threadcount
: Teilt die Synchronisierung auf mehrere Threads auf, um einen schnelleren Abschluss zu erreichen. Überlasten Sie Ihren Computer nicht und lassen Sie einen Teil der CPU für andere Aufgaben reserviert. Führen Sie zuerstnproc --all
aus, um die Anzahl der verfügbaren CPUs abzurufen.-q
: Durch das Unterdrücken von Statusmeldungen wird das Gerät im Hintergrund ausgeführt.-s
: Synchronisiert mit einem als fehlerfrei bekannten Build, wie durch das Elementmanifest-server
im aktuellen Manifest angegeben.
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 Repository die lokalen Zweige mit den Remote-Zweigen, die während der letzten Repository-Synchronisierung aktualisiert wurden. Das Repository fordert Sie auf, einen oder mehrere Zweige auszuwählen, die nicht zur Überprüfung hochgeladen wurden.
Alle Commits für die ausgewählten Zweige werden dann über eine HTTPS-Verbindung an Gerrit übertragen. Du musst ein HTTPS-Passwort konfigurieren, um die Upload-Autorisierung zu aktivieren. Wenn Sie ein neues Nutzername/Passwort-Paar für die Verwendung über HTTPS erstellen möchten, rufen Sie den Passwortgenerator auf.
Wenn Gerrit die Objektdaten über seinen Server empfängt, wird jedes Commit in eine Änderung umgewandelt, sodass Prüfer ein bestimmtes Commit kommentieren können.
Wenn Sie mehrere Checkpoint-Commits zu einem einzigen Commit kombinieren möchten, verwenden Sie vor dem Upload git rebase -i
.
Wenn Sie repo upload
ohne Argumente ausführen, werden alle Projekte nach Änderungen zum Hochladen durchsucht.
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. Nach Abschluss der Änderungen:
- Prüfen Sie, ob der aktualisierte Zweig der aktuell ausgecheckte Zweig ist.
- Verwenden Sie
repo upload --replace PROJECT
, um den Editor für Änderungsabgleiche zu öffnen. Geben Sie für jeden Commit in der Serie 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 wird für die Änderungen ein zusätzlicher Patchsatz erstellt.
Wenn Sie nur den aktuell geprüften Git-Branch hochladen möchten, verwenden Sie das Flag --current-branch
(kurz --cbr
).
Unterschied
repo diff [project-list]
Zeigt ausstehende Änderungen zwischen dem Commit und der Arbeitsstruktur mithilfe von git diff
an.
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
Durch die Ausführung von repo sync
werden alle mit repo download
abgerufenen Commits entfernt. Sie können auch mit git checkout m/main
den Remote-Zweig abrufen.
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, der in einen lokalen Tracking-Zweig übersetzt wird. Verwenden Sie diese Variable, wenn Sie die Manifest-Überarbeitung an einen lokal ausgeführten Git-Befehl übergeben müssen.REPO_RREV
ist der Name der Überarbeitung aus dem Manifest, genau wie im Manifest angegeben.
Optionen:
-c
: Befehl und Argumente, die ausgeführt werden sollen. Der Befehl wird über/bin/sh
und alle Argumente, nachdem er als Shell-Positionsparameter übergeben wurde, ausgewertet.-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 werden und die gesamte Ausgabe an einen kontinuierlichen Stream weitergeleitet wird, der in einer Single-Pager-Sitzung angezeigt wird.-v
: Zeigt Nachrichten an, die der Befehl in stderr schreibt.
Prune
repo prune [project-list]
Beseitigt (löscht) Themen, die bereits zusammengeführt wurden.
starten
repo start branch-name [project-list]
Startet einen neuen Zweig für die Entwicklung, beginnend mit der im Manifest angegebenen Überarbeitung.
Das Argument BRANCH_NAME
bietet eine kurze Beschreibung der Änderung, die Sie an den Projekten vornehmen möchten. Verwenden Sie den Namen default
, falls Sie ihn nicht kennen.
Das Argument project-list
gibt an, welche Projekte zu diesem Themenzweig gehören.
status
repo status [project-list]
Vergleicht den Arbeitsbaum mit dem Staging-Bereich (Index) und dem letzten Commit für diesen Zweig (HEAD) in jedem angegebenen Projekt. Zeigt eine Zusammenfassungszeile für jede Datei an, in der es einen Unterschied zwischen diesen drei Zuständen gibt.
Führen Sie repo status .
aus, um nur den Status des aktuellen Zweigs anzusehen. Die Statusinformationen sind nach Projekt aufgelistet. Für jede Datei im Projekt wird ein aus zwei Buchstaben bestehender Code verwendet.
In der ersten Spalte gibt ein Großbuchstaben an, wie sich der Staging-Bereich vom letzten Commit-Status unterscheidet.
Brief | 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 |
T | Gelöscht | In HEAD, 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 | Verbindung aufgehoben | Konflikt zwischen HEAD und Index; Auflösung erforderlich |
In der zweiten Spalte gibt ein Kleinbuchstabe an, wie sich das Arbeitsverzeichnis vom Index unterscheidet.
Brief | Bedeutung | Beschreibung |
---|---|---|
- | Neu/unbekannt | Nicht im Index, im Arbeitsbaum |
m | Geändert | Im Index, in der Arbeitsstruktur, 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
zu Beginn der Sitzung nicht ausgeführt wurde. Zur Wiederherstellung können Sie die Commit-ID prüfen, einen neuen Zweig starten und ihn dann zusammenführen.