Repozytorium uzupełnia Git, upraszczając pracę w wielu repozytoriach. Wyjaśnienie zależności między repozytorium a Git znajdziesz w artykule o narzędziach kontroli źródła. Więcej informacji o repozytorium znajdziesz w pliku README repozytorium.
Użycie repozytorium ma taką postać:
repo command options
Elementy opcjonalne są umieszczone w nawiasach kwadratowych []. Na przykład wiele poleceń przyjmuje wartość project-list jako argument. Możesz podać project-list jako 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
Zapewnia pomoc dotyczącą polecenia repo. Możesz wyświetlić szczegółowe informacje o konkretnym poleceniu repozytorium, które zawiera jedną z opcji:
repo help command
Na przykład poniższe polecenie zwraca opis i listę opcji polecenia init:
repo help init
Aby zobaczyć tylko listę dostępnych opcji polecenia, uruchom polecenie:
repo command --help
Przykład:
repo init --help
init
repo init -u url [options]
Instaluje repozytorium 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 ma być pobierane repozytorium pliku manifestu. Najczęstszy plik manifestu tohttps://android.googlesource.com/platform/manifest.-m: wybierz plik manifestu w repozytorium. Jeśli nie wybierzesz żadnej nazwy pliku manifestu, domyślna wartość todefault.xml.-b: określ wersję, czyli konkretną manifest-branch.
synchronizacja
repo sync [project-list]
Pobiera nowe zmiany i aktualizuje pliki robocze w środowisku lokalnym, co przekłada się na git fetch we wszystkich repozytoriach Git. Jeśli uruchomisz polecenie repo sync bez argumentów, zsynchronizuje pliki ze wszystkich projektów.
Po uruchomieniu repo sync:
Jeśli projekt nigdy nie był zsynchronizowany, projekt
repo syncjest odpowiednikiemgit clone; wszystkie gałęzie w repozytorium zdalnym są kopiowane do lokalnego katalogu projektu.Jeśli projekt został już wcześniej zsynchronizowany, funkcja
repo syncjest równoważna z:git remote update git rebase origin/branch
Gdzie branch to bieżąca rozliczona gałąź w katalogu projektów lokalnych. Jeśli gałąź lokalna nie śledzi gałęzi w zdalnym repozytorium, projekt nie zostaje zsynchronizowany.
Po udanym uruchomieniu zadania repo sync kod w określonych projektach jest aktualny i zsynchronizowany z kodem w repozytorium zdalnym.
Opcje klucza:
-c: pobierz z serwera tylko bieżącą gałąź pliku manifestu.-d: przełącz wybrane projekty z powrotem do wersji pliku manifestu. Ta opcja jest przydatna, jeśli projekt znajduje się w gałęzi tematu, ale wersja pliku manifestu jest potrzebna tymczasowo.-f: synchronizuj inne projekty, nawet jeśli nie uda się zsynchronizować projektu.threadcount: podziel synchronizację między wątki, aby przyspieszyć zakończenie. Nie przeciążaj komputera – pozostaw część procesora zarezerwowaną na potrzeby innych zadań. Aby zobaczyć liczbę dostępnych procesorów, najpierw uruchom polecenienproc --all.-q: działaj dyskretnie przez pomijanie komunikatów o stanie.-s: synchronizacja z dobrą kompilacją określoną przez elementmanifest-serverw bieżącym pliku manifestu.
Aby zobaczyć więcej opcji, uruchom repo help sync.
prześlij
repo upload [project-list]
Przesyła zmiany na serwer opinii. W określonych projektach Repo porównuje gałęzie lokalne z gałęziami zdalnymi zaktualizowanymi podczas ostatniej synchronizacji repozytorium. W repozytorium zobaczysz 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żywania przez HTTPS, otwórz generator haseł.
Gdy Gerrit otrzymuje dane obiektu przez swój serwer, zmienia każde zatwierdzenie w zmianę, dzięki czemu weryfikatorzy mogą komentować określone zatwierdzenie.
Aby połączyć kilka zatwierdzeń punktu kontrolnego w jedno zatwierdzenie, przed rozpoczęciem przesyłania użyj metody git rebase -i.
Jeśli uruchomisz funkcję repo upload bez argumentów, przeszukuje ona wszystkie projekty pod kątem zmian do przesłania.
Aby edytować zmiany po ich przesłaniu, skorzystaj z narzędzi takich jak git rebase -i lub git commit --amend, aby zaktualizować lokalne zatwierdzenia. Po wprowadzeniu zmian:
- Sprawdź, czy zaktualizowana gałąź to bieżąca rozliczona gałąź.
- Użyj elementu
repo upload --replace PROJECT, aby otworzyć edytor dopasowywania zmian. Dla 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 dla zmian zostanie ustawiona dodatkowa poprawka.
Jeśli chcesz przesłać tylko sprawdzoną obecnie gałąź Git, użyj flagi --current-branch (w skrócie --cbr).
różnice
repo diff [project-list]
Pokazuje oczekujące zmiany między zatwierdzeniem a drzewem roboczym za pomocą funkcji git diff.
pobierz
repo download target change
Pobiera określoną zmianę z systemu weryfikacji i udostępnia ją w lokalnym katalogu roboczym projektu.
Przykład: aby pobrać zmianę 23823 do katalogu platform/build:
repo download platform/build 23823
Uruchomienie repo sync spowoduje usunięcie wszystkich zatwierdzeń pobranych za pomocą repo download. Możesz też sprawdzić gałąź zdalną za pomocą 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_PROJECTma unikalną nazwę projektu.REPO_PATHto ścieżka względem katalogu głównego klienta.REPO_REMOTEto nazwa systemu zdalnego z pliku manifestu.REPO_LREVto nazwa wersji z pliku manifestu przetłumaczona na lokalną gałąź śledzenia. Użyj tej zmiennej, jeśli chcesz przekazać wersję pliku manifestu do lokalnego polecenia Gita.REPO_RREVto nazwa wersji z pliku manifestu, dokładnie w takiej postaci, w jakiej jest ona zapisana w pliku manifestu.
Opcje:
-c: polecenie i argumenty do wykonania. Polecenie jest oceniane przez/bin/shi wszystkie kolejne argumenty przekazywane jako parametry pozycjonujące powłokę.-p: wyświetlaj nagłówki projektu przed danymi wyjściowymi określonego polecenia. Jest to możliwe dzięki powiązaniu potoków ze strumieniami stdin, stdout i sterr polecenia oraz przez połączenie wszystkich danych wyjściowych w ciągłym strumieniu, który jest wyświetlany w ramach pojedynczej sesji pagera.-v: pokazuje komunikaty, które polecenie zapisuje w stderr.
przytnij
repo prune [project-list]
Przycina (usuwa) tematy, które zostały już scalone.
start
repo start branch-name [project-list]
Rozpoczyna nową gałąź na potrzeby programowania, zaczynając od wersji określonej w pliku manifestu.
Argument BRANCH_NAME zawiera krótki opis zmiany, którą próbujesz wprowadzić w projektach. Jeśli go nie znasz, użyj nazwy default.
Argument project-list określa, które projekty należą do tej gałęzi tematu.
status
repo status [project-list]
Porównuje drzewo robocze z obszarem przejściowym (indeksem) i najnowszym zatwierdzeniem w tej gałęzi (HEAD) w każdym podanym projekcie. Wyświetla wiersz podsumowania dla każdego pliku, w którym występuje różnica między tymi 3 stanami.
Aby wyświetlić tylko stan bieżącej gałęzi, uruchom polecenie repo status .. Informacje o stanie są wyświetlane według projektów. Każdy plik w projekcie
ma dwuliterowy kod.
W pierwszej kolumnie duża litera wskazuje, w jaki sposób obszar przejściowy różni się od ostatniego stanu zatwierdzenia.
| Letter | Znaczenie | Opis |
|---|---|---|
| - | Bez zmian | Ta sama w elemencie HEAD i w indeksie |
| O | Dodano | Brak w sekcji HEAD, w indeksie |
| M | Data modyfikacji | W elemencie HEAD, zmodyfikowana w indeksie |
| D | Usunięte | W sekcji HEAD, ale nie w indeksie |
| R | Nazwa została zmieniona | Nie w HEAD, ścieżka w indeksie została zmieniona |
| C | Skopiowano | Brak w sekcji HEAD, skopiowano z innego indeksu |
| T | Tryb został zmieniony | Ta sama treść w HEAD i indeksie, tryb zmieniony |
| U | Rozdzielono | Konflikt między HEAD a indeksem; wymagane rozwiązanie |
W drugiej kolumnie mała litera wskazuje, czym różni się katalog roboczy od indeksu.
| Letter | Znaczenie | Opis |
|---|---|---|
| - | Nowe/nieznane | Brak indeksu, w drzewie roboczym |
| min | Data modyfikacji | Zmodyfikowano w indeksie, w drzewie roboczym |
| D | Usunięte | W indeksie, nie w drzewie roboczym |
Postępowanie w przypadku 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ć dane, możesz sprawdzić identyfikator zatwierdzenia, uruchomić nową gałąź, a następnie ją scalić.