Repo uzupełnia Git, upraszczając pracę w wielu repozytoriach. Więcej informacji o relacji między repozytorium a Git znajdziesz w artykule Narzędzia do kontroli wersji. Więcej informacji o Repo znajdziesz w README repozytorium.
Korzystanie z repozytorium:
repo command options
Elementy opcjonalne są wyświetlane w nawiasach []. Na przykład wiele poleceń przyjmuje jako argument project-list. Możesz podać parametr project-list jako listę nazw lub listę ścieżek do lokalnych katalogów źródłowych w przypadku projektów:
repo sync [project0 project1 ... projectn]
repo sync [/path/to/project0 ... /path/to/projectn]
pomoc
repo help
Udostępnia pomoc dotyczącą polecenia repo
. Szczegółowe informacje o konkretnym poleceniu Repo możesz zobaczyć, podając je jako opcję:
repo help command
Na przykład poniższe polecenie wyświetla opis i listę opcji polecenia init
:
repo help init
Aby wyświetlić tylko listę dostępnych opcji polecenia, uruchom:
repo command --help
Przykład:
repo init --help
init
repo init -u url [options]
Instaluje Repo w bieżącym katalogu. To polecenie tworzy .repo/
katalog z repozytoriami Git dla kodu źródłowego repozytorium oraz standardowych plików manifestu Androida.
Opcje:
-u
: podaj adres URL, z którego chcesz pobrać repozytorium pliku manifestu. Wspólny plik manifestu znajduje się pod adresemhttps://android.googlesource.com/platform/manifest
.-m
: wybierz plik manifestu w repozytorium. Jeśli nie wybierzesz nazwy pliku manifestu, zostanie użyta domyślna wartośćdefault.xml
.-b
: określenie wersji, czyli konkretnej manifest-branch.
synchronizacja
repo sync [project-list]
Pobiera nowe zmiany i aktualizuje pliki robocze w środowisku lokalnym, co w istocie oznacza wykonanie polecenia git fetch
we wszystkich repozytoriach Git. Jeśli uruchomisz polecenie repo sync
bez argumentów, spowoduje to zsynchronizowanie plików we wszystkich projektach.
Gdy uruchomisz repo sync
, nastąpi:
Jeśli projekt nigdy nie był synchronizowany,
repo sync
jest równoznaczne zgit clone
; wszystkie gałęzie w zdalnym repozytorium są kopiowane do lokalnego katalogu projektu.Jeśli projekt był już synchronizowany,
repo sync
jest równoważne:git remote update git rebase origin/branch
Gdzie branch to bieżąca wypisana gałąź w lokalnym katalogu projektu. Jeśli lokalna gałąź nie śledzi gałęzi w zdalnym repozytorium, nie następuje synchronizacja projektu.
Po pomyślnym uruchomieniu polecenia repo sync
kod w określonych projektach jest aktualny i zsynchronizowany z kodem w zdalnym repozytorium.
Opcje klucza:
-c
: pobieraj z serwera tylko bieżącą gałąź pliku manifestu.-d
: przełącz wybrane projekty z powrotem na wersję pliku manifestu. Ta opcja jest przydatna, jeśli projekt znajduje się na gałęzi tematu, ale tymczasowo potrzebna jest wersja pliku manifestu.-f
: kontynuuj synchronizację innych projektów, nawet jeśli nie uda się zsynchronizować jednego z nich.threadcount
: podziel synchronizację na wątki, aby przyspieszyć proces. Nie przeciążaj komputera – zostaw trochę procesora na potrzeby innych zadań. Aby zobaczyć liczbę dostępnych procesorów, najpierw uruchom polecenienproc --all
.-q
: uruchamianie w tle przez pominięcie komunikatów o stanie.-s
: zsynchronizuj z wersją kompilacji, która działa prawidłowo, zgodnie z elementemmanifest-server
w bieżącym pliku manifestu.
Aby wyświetlić więcej opcji, uruchom repo help sync
.
prześlij
repo upload [project-list]
Przesyła zmiany na serwer sprawdzania. W przypadku określonych projektów Repo porównuje gałęzie lokalne z gałęziami zdalnymi zaktualizowanymi podczas ostatniej synchronizacji repozytorium. Repo wyświetli prośbę o wybranie co najmniej jednej gałęzi, która nie została przesłana do sprawdzenia.
Wszystkie zatwierdzenia w wybranych gałęziach są następnie przesyłane do Gerrit za pomocą połączenia HTTPS. Aby włączyć autoryzację przesyłania, musisz skonfigurować hasło HTTPS. Aby wygenerować nową parę nazwa użytkownika/hasło do użycia w protokole HTTPS, skorzystaj z Generatora haseł.
Gdy Gerrit otrzyma dane obiektu na swoim serwerze, przekształci każde potwierdzenie w zmianę, aby recenzenci mogli komentować konkretne potwierdzenia.
Aby połączyć kilka zatwierdzeń punktów kontrolnych w jedną wersję, przed przesłaniem użyj opcji git rebase -i
.
Jeśli uruchomisz polecenie 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
, aby zaktualizować lokalne zatwierdzenia. Po wprowadzeniu zmian:
- Sprawdź, czy zaktualizowana gałąź jest aktualnie wymeldowaną gałęzią.
- Użyj
repo upload --replace PROJECT
, aby otworzyć edytor dopasowywania zmian. W przypadku każdego zatwierdzenia w serii wpisz identyfikator zmiany w Gerricie 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 replacements # 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 zostaną objęte dodatkowym zestawem poprawek.
Jeśli chcesz przesłać tylko bieżącą gałąź Git, użyj flagi --current-branch
(lub --cbr
w skrócie).
W przypadku powiązanych zmian warto zachować wszystkie CL w tym samym temacie. Możesz dodać nazwę tematu podczas przesyłania za pomocą --topic=TOPIC
. Możesz też przekazać parametr -t
, aby ustawić nazwę tematu taką samą jak nazwa lokalnej gałęzi.
różnice
repo diff [project-list]
za pomocą git diff
pokazuje nierozpatrzone zmiany między zatwierdzeniami a drzewem roboczym.
pobierz
repo download target change
Pobiera określoną zmianę z systemu sprawdzania i czyni ją dostępną w lokalnym katalogu roboczym projektu.
Aby na przykład pobrać change 23823 do katalogu platform/build
:
repo download platform/build 23823
Uruchomienie polecenia repo sync
spowoduje usunięcie wszystkich zatwierdzeń pobranych za pomocą polecenia repo download
. Możesz też wybrać gałąź zdalna za pomocą polecenia git checkout m/main
.
forall
repo forall [project-list] -c command
Wykonuje podane polecenie w każdym projekcie. Te dodatkowe zmienne środowiska są dostępne w usłudze repo forall
:
REPO_PROJECT
ma ustawioną niepowtarzalną nazwę projektu.REPO_PATH
to ścieżka w odniesieniu do katalogu głównego klienta.REPO_REMOTE
to nazwa zdalnego systemu z pliku manifestu.REPO_LREV
to nazwa wersji z pliku manifestu przekształcona w lokalną gałąź śledzenia. Użyj tej zmiennej, jeśli chcesz przekazać wersję pliku manifestu do lokalnie wykonanego polecenia Git.REPO_RREV
to nazwa wersji z pliku manifestu, dokładnie tak, jak jest zapisana w pliku.
Opcje:
-c
: polecenie i argumenty do wykonania. Polecenie jest oceniane za pomocą funkcji/bin/sh
, a wszystkie argumenty po nim są przekazywane jako parametry pozycyjne powłoki.-p
: przed wyświetleniem danych wyjściowych określonego polecenia wyświetla nagłówki projektu. Osiąga się to przez wiązanie przewodów z wejściem standardowym, wyjściem standardowym i strumieniami sterr polecenia oraz przekierowanie całego wyjścia do ciągłego strumienia, który jest wyświetlany w jednej sesji przeglądarki.-v
: wyświetla komunikaty, które polecenie zapisuje w stderr.
śliwka
repo prune [project-list]
usuwa tematy, które zostały już scalone.
rozpocznij
repo start branch-name [project-list]
Rozpoczyna nową gałąź do rozwoju, zaczynając od wersji określonej w pliku manifestu.
Argument BRANCH_NAME
zawiera krótki opis zmiany, którą chcesz wprowadzić w projektach. Jeśli nie znasz nazwy, użyj nazwy default
.
Argument project-list
określa, które projekty uczestniczą w tej gałęzi tematu.
status
repo status [project-list]
Porównuje drzewo robocze z obszarem pośrednim (indeksem) i najnowszym zatwierdzonym elementem 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 3 stanami.
Aby zobaczyć stan tylko bieżącej gałęzi, uruchom repo status .
. Informacje o stanie są wyświetlane według projektu. W przypadku każdego pliku w projekcie używany jest dwuliterowy kod.
W pierwszej kolumnie wielka litera wskazuje, czym obszar stagingu różni się od ostatniego stanu.
List | Znaczenie | Opis |
---|---|---|
- | Bez zmian | Takie same w sekcji nagłówka i indeksie |
A | Dodano | Nie w sekcji HEAD, ale w indeksie |
M | Data modyfikacji | W wycinku głównym, zmodyfikowane w indeksie |
D | Usunięte | W sekcji HEAD, nie w indeksie |
R | Nazwa została zmieniona | Nie w sekcji HEAD, ścieżka zmieniona w indeksie |
C | Skopiowano | Brak w głównym pliku, skopiowane z innego w indeksie |
T | Zmieniono tryb | Ta sama treść w pliku HEAD i indeksie, zmieniony tryb |
U | Niezłączone | Konflikt między HEAD a indeksem; wymagane rozwiązanie |
W drugiej kolumnie mała litera wskazuje, czym różni się katalog roboczy od indeksu.
List | Znaczenie | Opis |
---|---|---|
- | Nowy/nieznany | Brak w indeksie, w drzewie |
min | Data modyfikacji | W indeksie, w drzewie roboczym, zmodyfikowany |
d | Usunięte | w indeksie, ale nie w drzewie |
Obsługa błędów repozytorium
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 polecenie
repo start
nie zostało wykonane na początku sesji. Aby przywrócić zmiany, możesz sprawdzić identyfikator zatwierdzenia, utworzyć nową gałąź i scalić ją.