Repo uzupełnia Git, upraszczając pracę w wielu repozytoriach. Wyjaśnienie zależności między Repo a Gitem znajdziesz w artykule Narzędzia do kontroli wersji. Więcej informacji o Repo znajdziesz w pliku README Repo.
Korzystanie z repozytorium ma następującą formę:
repo command options
Elementy opcjonalne są wyświetlane w nawiasach kwadratowych []. Na przykład wiele poleceń przyjmuje argument project-list. Możesz określić project-listjako listę nazw lub listę ścieżek do lokalnych katalogów źródłowych projektów:
repo sync [project0 project1 ... projectn]
repo sync [/path/to/project0 ... /path/to/projectn]
pomoc
repo help
Wyświetla pomoc dotyczącą polecenia repo
. Szczegółowe informacje o konkretnym poleceniu Repo możesz wyświetlić, podając je jako opcję:
repo help command
Na przykład to 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
Na przykład:
repo init --help
init
repo init -u url [options]
Instaluje Repo w bieżącym katalogu. To polecenie tworzy katalog .repo/
z repozytoriami Git dla kodu źródłowego Repo i standardowych plików manifestu Androida.
Opcje:
-u
: podaj adres URL, z którego chcesz pobrać repozytorium manifestu. Wspólny plik manifestu znajduje się w lokalizacjihttps://android.googlesource.com/platform/manifest
.-m
: wybierz plik manifestu w repozytorium. Jeśli nie wybierzesz nazwy pliku manifestu, domyślnie zostanie użyta nazwadefault.xml
.-b
: określ wersję, czyli konkretny element manifest-branch.
synchronizacja
repo sync [project-list]
Pobiera nowe zmiany i aktualizuje pliki robocze w środowisku lokalnym, co w zasadzie odpowiada wykonaniu polecenia git fetch
we wszystkich repozytoriach Git. Jeśli uruchomisz polecenie
repo sync
bez argumentów, zsynchronizuje ono pliki wszystkich projektów.
Gdy uruchomisz repo sync
, wykonane zostaną te działania:
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ż wcześniej synchronizowany, wartość
repo sync
jest równa:git remote update git rebase origin/branch
gdzie branch to aktualna gałąź w lokalnym katalogu projektu. Jeśli lokalna gałąź nie śledzi gałęzi w zdalnym repozytorium, projekt nie jest synchronizowany.
Po pomyślnym uruchomieniu polecenia repo sync
kod w określonych projektach jest aktualny i zsynchronizowany z kodem w repozytorium zdalnym.
Najważniejsze opcje:
-c
: pobieraj z serwera tylko bieżącą gałąź pliku manifestu.-d
: przywróć określone projekty do wersji manifestu. Ta opcja jest przydatna, jeśli projekt znajduje się w gałęzi tematycznej, ale tymczasowo potrzebna jest wersja pliku manifestu.-f
: kontynuuj synchronizację innych projektów, nawet jeśli synchronizacja jednego z nich się nie powiedzie.-j threadcount
: podziel synchronizację na wątki, aby przyspieszyć jej zakończenie. Nie obciążaj zbytnio komputera – zostaw trochę mocy obliczeniowej procesora na inne zadania. Aby sprawdzić liczbę dostępnych procesorów, najpierw uruchom polecenienproc --all
.-q
: uruchamiaj w trybie cichym, pomijając komunikaty o stanie.-s
: Synchronizacja z znaną dobrą kompilacją określoną przez elementmanifest-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 weryfikacyjny. W przypadku określonych projektów Repo porównuje lokalne gałęzie z gałęziami zdalnymi zaktualizowanymi podczas ostatniej synchronizacji Repo. Repo wyświetli prośbę o wybranie co najmniej 1 gałęzi, która nie została przesłana do sprawdzenia.
Wszystkie zatwierdzenia w wybranych gałęziach są następnie przesyłane do Gerrit przez połączenie HTTPS. Aby włączyć autoryzację przesyłania, musisz skonfigurować hasło HTTPS. Aby wygenerować nową parę nazwy użytkownika i hasła do użycia w protokole HTTPS, odwiedź generator haseł.
Gdy Gerrit otrzyma dane obiektu na swoim serwerze, przekształci każdy commit w zmianę, aby osoby sprawdzające mogły komentować konkretny commit.
Aby połączyć kilka zatwierdzeń punktu kontrolnego w jedno zatwierdzenie, przed przesłaniem użyj polecenia git rebase -i
.
Jeśli uruchomisz polecenie repo upload
bez argumentów, wyszuka ono we wszystkich projektach zmiany 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 obecnie wyewidencjonowaną gałęzią.
- Użyj skrótu
repo upload --replace PROJECT
, aby otworzyć edytor dopasowywania zmian. W przypadku każdego zatwierdzenia w serii wpisz identyfikator zmiany Gerrit 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 mają dodatkowy zestaw poprawek.
Jeśli chcesz przesłać tylko aktualnie wybraną gałąź Git, użyj flagi
--current-branch
(lub --cbr
w skrócie).
W przypadku powiązanych zmian warto umieścić wszystkie listy zmian w tym samym temacie. Podczas przesyłania za pomocą --topic=TOPIC
możesz dodać nazwę tematu. Możesz też przekazać -t
do funkcji set, aby ustawić nazwę tematu taką samą jak nazwa gałęzi lokalnej.
diff
repo diff [project-list]
Wyświetla oczekujące zmiany między zatwierdzeniem a drzewem roboczym za pomocą polecenia git diff
.
pobierz
repo download target change
Pobiera z systemu sprawdzania określone zmiany i udostępnia je 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
usuwa wszystkie zatwierdzenia pobrane za pomocą polecenia repo download
. Możesz też sprawdzić gałąź zdalną za pomocą polecenia git checkout m/main
.
forall
repo forall [project-list] -c command
Wykonuje podane polecenie powłoki w każdym projekcie. repo forall
udostępnia te dodatkowe zmienne środowiskowe:
REPO_PROJECT
jest ustawiona na unikalną nazwę projektu.REPO_PATH
to ścieżka względna względem katalogu głównego klienta.REPO_REMOTE
to nazwa systemu zdalnego z manifestu.REPO_LREV
to nazwa wersji z pliku manifestu przetłumaczona na lokalną gałąź śledzenia. Użyj tej zmiennej, jeśli chcesz przekazać wersję manifestu do lokalnie wykonywanego polecenia Git.REPO_RREV
to nazwa wersji z pliku manifestu, dokładnie taka, jak w pliku manifestu.
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
: wyświetla nagłówki projektów przed wygenerowaniem danych wyjściowych określonego polecenia. Osiąga się to przez powiązanie potoków ze strumieniami stdin, stdout i sterr polecenia oraz przekierowanie wszystkich danych wyjściowych do ciągłego strumienia, który jest wyświetlany w ramach jednej sesji stronicowania.-v
: wyświetla wiadomości, które polecenie zapisuje w stderr.
przycinanie,
repo prune [project-list]
Usuwa (trwale usuwa) tematy, które zostały już scalone.
rozpocznij
repo start branch-name [project-list]
Rozpoczyna nową gałąź 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, możesz użyć 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 przejściowym (indeksem) i ostatnim zatwierdzeniem w tym projekcie (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 wyświetlić stan tylko bieżącej gałęzi, uruchom polecenie repo status .
. Informacje o stanie są podane dla każdego projektu. W przypadku każdego pliku w projekcie używany jest dwuliterowy kod.
W pierwszej kolumnie wielka litera wskazuje, czym obszar roboczy różni się od ostatniego zatwierdzonego stanu.
List | Znaczenie | Opis |
---|---|---|
- | Bez zmian | Taka sama w HEAD i indeksie |
A | Dodane | Brak w sekcji HEAD, w indeksie |
M | Data modyfikacji | W wycinku głównym, zmodyfikowano w indeksie |
D | Usunięto | W sekcji HEAD, ale nie w indeksie |
R | Nazwa została zmieniona | Brak w sekcji HEAD, ścieżka zmieniona w indeksie |
C | Skopiowano | Brak w HEAD, skopiowano z innego w indeksie |
T | Zmieniono tryb | Ta sama treść w sekcjach HEAD i index, zmieniony tryb |
U | Niepołączone | Konflikt między HEAD a indeksem; wymagane rozwiązanie |
W drugiej kolumnie mała litera wskazuje, czym katalog roboczy różni się od indeksu.
List | Znaczenie | Opis |
---|---|---|
- | Nowy/nieznany | Brak w indeksie, w drzewie roboczym |
m | Data modyfikacji | W indeksie, w drzewie roboczym, zmodyfikowano |
d | Usunięto | W indeksie, ale nie w drzewie roboczym |
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 uruchomione na początku sesji. Aby przywrócić zmiany, możesz sprawdzić identyfikator zatwierdzenia, utworzyć nową gałąź, a następnie ją scalić.