Odniesienie do polecenia repo

Repo uzupełnia Git, upraszczając pracę w wielu repozytoriach. Aby uzyskać wyjaśnienie relacji pomiędzy Repo i Git, zobacz Narzędzia kontroli źródła . 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

repo help

Zawiera pomoc dotyczącą polecenia repo . Możesz zobaczyć szczegółowe informacje na temat konkretnego polecenia Repo, podając polecenie jako opcję:

repo help command

Na przykład następujące polecenie wyświetla opis i listę opcji polecenia init :

repo help init

Lub, aby wyświetlić tylko listę dostępnych opcji polecenia, uruchom:

repo command --help

Na przykład:

repo init --help

w tym

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 : Określ adres URL, z którego chcesz pobrać repozytorium manifestu. Wspólny manifest można znaleźć pod https://android.googlesource.com/platform/manifest .

  • -m : Wybierz plik manifestu w repozytorium. Jeśli nie wybrano żadnej nazwy manifestu, domyślną nazwą jest default.xml .

  • -b : Określ wersję, czyli konkretną manifest-branch .

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żna git 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.

Po pomyślnym uruchomieniu repo sync kod w określonych projektach jest aktualny i synchronizowany z kodem w zdalnym repozytorium.

Kluczowe opcje:

  • -c : Pobierz tylko bieżącą gałąź manifestu z serwera.
  • -d : Przełącz określone projekty z powrotem do wersji manifestu. Ta opcja jest pomocna, jeśli projekt znajduje się w gałęzi tematycznej, ale wersja manifestu jest potrzebna tymczasowo.
  • -f : Kontynuuj synchronizację innych projektów, nawet jeśli synchronizacja projektu nie powiedzie się.
  • threadcount : Podziel synchronizację na wątki, aby przyspieszyć 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.

Aby uzyskać więcej opcji, uruchom repo help sync .

wgrywać

repo upload [project-list]

Przesyła zmiany na serwer recenzji. 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. Aby wygenerować nową parę nazwa użytkownika/hasło do użycia przez HTTPS, odwiedź generator haseł .

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 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ą 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 platform/build :

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 .

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 zmiennej, 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.

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żącego oddziału, 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ługuj błędy 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ą scalić.