Repo uzupełnia Git, upraszczając pracę w wielu repozytoriach. Zobacz Narzędzia kontroli źródła , aby uzyskać wyjaśnienie relacji między Repo i Git. Więcej informacji na temat Repo można znaleźć w pliku README Repo .
Użycie repo ma następującą formę:
repo command options
Elementy opcjonalne pokazano w nawiasach [ ]. Na przykład wiele poleceń przyjmuje jako argument project-list . Możesz określić project-list jako listę nazw lub listę ścieżek do lokalnych katalogów źródłowych dla projektów:
repo sync [project0 project1 ... projectn]
repo sync [/path/to/project0 ... /path/to/projectn]
pomoc
Ta strona jedynie podkreśla najważniejsze opcje. Szczegółowe informacje można znaleźć w pomocy wiersza poleceń. Po zainstalowaniu Repo możesz znaleźć najnowszą dokumentację, zaczynając od podsumowania wszystkich poleceń, uruchamiając:
repo help
Możesz zobaczyć szczegółowe informacje o dowolnym poleceniu, uruchamiając je w drzewie Repo:
repo help command
Na przykład poniższe polecenie wyświetla opis i listę opcji dla argumentu init
Repo, który inicjuje Repo w bieżącym katalogu. (Szczegółowe informacje znajdziesz w init .)
repo help init
Lub aby zobaczyć tylko listę dostępnych opcji, uruchom:
repo command --helpNa przykład:
repo init --help
w tym
repo init -u url [options]
Instaluje Repo w bieżącym katalogu. Spowoduje to utworzenie katalogu .repo/
z repozytoriami Git dla kodu źródłowego Repo i standardowych plików manifestu Androida.
Opcje:
-
-u
: Określ adres URL, z którego chcesz pobrać repozytorium manifestu. Wspólny manifest można znaleźć podhttps://android.googlesource.com/platform/manifest
. -
-m
: Wybierz plik manifestu w repozytorium. Jeśli nie wybrano żadnej nazwy manifestu, domyślną nazwą jestdefault.xml
. -
-b
: Określ wersję, czyli konkretną manifest-branch .
Uwaga: w przypadku wszystkich pozostałych poleceń Repo bieżący katalog roboczy musi być albo katalogiem nadrzędnym .repo/
, albo podkatalogiem katalogu nadrzędnego.
synchronizacja
repo sync [project-list]
Pobiera nowe zmiany i aktualizuje działające pliki w twoim środowisku lokalnym, zasadniczo wykonując git fetch
we wszystkich repozytoriach Git. Jeśli uruchomisz repo sync
bez argumentów, zsynchronizuje ona pliki wszystkich projektów.
Po uruchomieniu repo sync
dzieje się tak:
Jeśli projekt nigdy nie był synchronizowany,
repo sync
jest równoważnagit clone
. Wszystkie gałęzie w zdalnym repozytorium są kopiowane do lokalnego katalogu projektu.Jeśli projekt był już wcześniej synchronizowany,
repo sync
jest równoznaczna z:git remote update git rebase origin/branch
gdzie
branch
jest aktualnie wyewidencjonowaną gałęzią w lokalnym katalogu projektu. Jeśli oddział lokalny nie śledzi oddziału w zdalnym repozytorium, wówczas dla projektu nie nastąpi synchronizacja.Jeśli operacja Git rebase powoduje konflikty scalania, użyj zwykłych poleceń Git (na przykład
git rebase --continue
), aby rozwiązać konflikty.
Po pomyślnym uruchomieniu repo sync
kod w określonych projektach jest aktualny i synchronizowany z kodem w zdalnym repozytorium.
Oto najważniejsze opcje. Zobacz repo help sync
aby uzyskać więcej informacji:
-c
: Pobierz tylko bieżącą gałąź manifestu z serwera.-d
: Przełącz określone projekty z powrotem do wersji manifestu. Jest to przydatne, jeśli projekt znajduje się obecnie w gałęzi tematycznej, ale tymczasowo potrzebna jest wersja manifestu.-f
: Kontynuuj synchronizację innych projektów, nawet jeśli synchronizacja projektu nie powiedzie się.-j threadcount
: Podziel synchronizację na wątki, aby przyspieszyć jej zakończenie. Upewnij się, że nie przeciążasz swojej maszyny – zostaw trochę procesora zarezerwowanego na inne zadania. Aby zobaczyć liczbę dostępnych procesorów, najpierw uruchom:nproc --all
-q
: Działa cicho, pomijając komunikaty o stanie.-s
: Synchronizuj ze znaną dobrą kompilacją określoną przez element manifest-server w bieżącym manifeście.
wgrywać
repo upload [project-list]
W przypadku określonych projektów Repo porównuje gałęzie lokalne z gałęziami zdalnymi zaktualizowanymi podczas ostatniej synchronizacji Repo. Repo poprosi Cię o wybranie jednego lub więcej oddziałów, które nie zostały przesłane do sprawdzenia.
Wszystkie zatwierdzenia w wybranych gałęziach są następnie przesyłane do Gerrita za pośrednictwem połączenia HTTPS. Aby włączyć autoryzację przesyłania, musisz skonfigurować hasło HTTPS. Odwiedź Generator haseł , aby wygenerować nową parę nazwa użytkownika/hasło do użycia przez HTTPS.
Kiedy Gerrit otrzymuje dane opisowe ze swojego serwera, każde zatwierdzenie zamienia w zmianę, dzięki czemu recenzenci mogą komentować konkretne zatwierdzenia. Aby połączyć kilka zatwierdzeń punktów kontrolnych w jedno, użyj git rebase -i
przed uruchomieniem przesyłania.
Jeśli uruchomisz repo upload
bez argumentów, przeszuka ono wszystkie projekty pod kątem zmian do przesłania.
Aby edytować zmiany po ich przesłaniu, użyj narzędzia takiego jak git rebase -i
lub git commit --amend
w celu zaktualizowania lokalnych zatwierdzeń. Po zakończeniu edycji:
- Sprawdź, czy zaktualizowana gałąź jest aktualnie wyewidencjonowaną gałęzią.
- Użyj
repo upload --replace PROJECT
aby otworzyć edytor dopasowywania zmian. - Dla każdego zatwierdzenia w serii wprowadź identyfikator zmiany Gerrita w nawiasach:
# Replacing from branch foo [ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific... [ 2829 ] ec18b4ba Update proto client to support patch set replacments # Insert change numbers in the brackets to add a new patch set. # To create a new change record, leave the brackets empty.
Po zakończeniu przesyłania zmiany mają zestaw dodatkowej łatki.
Jeśli chcesz przesłać tylko aktualnie wyewidencjonowaną gałąź Git, użyj flagi --current-branch
(lub w skrócie --cbr
).
różnica
repo diff [project-list]
Pokazuje zaległe zmiany między zatwierdzeniem a drzewem roboczym za pomocą git diff
.
pobierać
repo download target change
Pobiera określoną zmianę z systemu recenzji i udostępnia ją w lokalnym katalogu roboczym projektu.
Na przykład, aby pobrać zmianę 23823 do katalogu platformy/kompilacji:
repo download platform/build 23823
Uruchomienie repo sync
usuwa wszelkie zatwierdzenia pobrane podczas repo download
. Możesz też sprawdzić zdalną gałąź za pomocą git checkout m/main
.
Uwaga: występują opóźnienia w replikacji na wszystkich serwerach na całym świecie, dlatego występuje niewielkie opóźnienie lustrzane pomiędzy momentem, gdy zmiana jest widoczna w Internecie w Gerrit , a momentem, w którym repo download
może znaleźć zmianę dla wszystkich użytkowników.
dla wszystkich
repo forall [project-list] -c command
Wykonuje podane polecenie powłoki w każdym projekcie. repo forall
udostępnia następujące dodatkowe zmienne środowiskowe:
REPO_PROJECT
jest ustawiona na unikalną nazwę projektu.REPO_PATH
to ścieżka względem katalogu głównego klienta.REPO_REMOTE
to nazwa systemu zdalnego z manifestu.REPO_LREV
to nazwa wersji z manifestu, przetłumaczona na lokalną gałąź śledzenia. Użyj tej opcji, jeśli chcesz przekazać wersję manifestu do lokalnie wykonywanego polecenia Git.REPO_RREV
to nazwa wersji z manifestu, dokładnie taka, jak zapisano w manifeście.
Opcje:
-c
: Polecenie i argumenty do wykonania. Polecenie jest oceniane poprzez/bin/sh
, a wszelkie argumenty po nim przekazywane są jako parametry pozycyjne powłoki.-p
: Pokaż nagłówki projektu przed wyjściem określonego polecenia. Osiąga się to poprzez powiązanie potoków ze strumieniami stdin, stdout i sterr polecenia i potokowanie całego wyjścia w ciągły strumień, który jest wyświetlany w pojedynczej sesji pagera.-v
: Pokaż komunikaty, które polecenie zapisuje na stderr.
suszona śliwka
repo prune [project-list]
Przycina (usuwa) tematy, które zostały już scalone.
początek
repo start branch-name [project-list]
Rozpoczyna nową gałąź rozwoju, zaczynając od wersji określonej w manifeście.
Argument BRANCH_NAME
zawiera krótki opis zmiany, którą próbujesz wprowadzić w projektach. Jeśli nie wiesz, rozważ użycie nazwy default
.
Argument project-list
określa, które projekty uczestniczą w tej gałęzi tematycznej.
Uwaga: Kropka ( . ) jest skrótem oznaczającym projekt w bieżącym katalogu roboczym.
status
repo status [project-list]
Porównuje drzewo robocze z obszarem przejściowym (indeks) i najnowszym zatwierdzeniem w tej gałęzi (HEAD) w każdym określonym projekcie. Wyświetla wiersz podsumowania dla każdego pliku, w którym występuje różnica między tymi trzema stanami.
Aby zobaczyć status tylko bieżącej gałęzi, uruchom repo status .
. Informacje o statusie są wyświetlane według projektów. Dla każdego pliku w projekcie stosowany jest dwuliterowy kod.
W pierwszej kolumnie wielka litera wskazuje, w jaki sposób obszar przejściowy różni się od ostatniego zatwierdzonego stanu.
List | Oznaczający | Opis |
---|---|---|
- | Bez zmiany | To samo w HEAD i indeksie |
A | Dodany | Nie w HEAD, w indeksie |
M | Zmodyfikowany | W HEAD, zmodyfikowany w indeksie |
D | Usunięto | W HEAD, a nie w indeksie |
R | Zmieniono nazwę | Nie w HEAD, ścieżka zmieniona w indeksie |
C | Skopiowano | Nie w HEAD, skopiowane z innego w indeksie |
T | Tryb zmieniony | Ta sama zawartość w HEAD i indeksie, tryb zmieniony |
U | Niepołączone | Konflikt pomiędzy HEAD a indeksem; wymagana uchwała |
W drugiej kolumnie mała litera wskazuje, czym katalog roboczy różni się od indeksu.
List | Oznaczający | Opis |
---|---|---|
- | Nowy/nieznany | Nie w indeksie, w drzewie roboczym |
M | Zmodyfikowany | W indeksie, w drzewie roboczym, zmodyfikowane |
D | Usunięto | W indeksie, a nie w drzewie roboczym |
Obsługa błędów repo
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 .
Błąd repo: error: no branches ready for upload
pojawia się, gdy na początku sesji nie uruchomiono polecenia repo start
. Aby odzyskać, możesz sprawdzić identyfikator zatwierdzenia, rozpocząć nową gałąź, a następnie ją połączyć.