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 syncjest 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 syncjest 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-serverw 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_PROJECTjest ustawiona na unikalną nazwę projektu.REPO_PATHto ścieżka względna względem katalogu głównego klienta.REPO_REMOTEto nazwa systemu zdalnego z manifestu.REPO_LREVto 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_RREVto 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ć.
Struktura repozytorium Git
W przypadku Androida repozytoria Git (projekty) nie są zagnieżdżone. Każdy projekt jest powiązany z określonym katalogiem w drzewie źródłowym, a wszystkie podkatalogi i pliki w tym katalogu należą do tego samego projektu.
Unikaj używania funkcji git submodule w Repo podczas tworzenia aplikacji na Androida.