Dokumentacja polecenia repozytorium

Repozytorium uzupełnia Git, upraszczając pracę w wielu repozytoriach. Dla na temat zależności między Repo a Git; zapoznaj się z Narzędzia do sterowania źródłem. Więcej szczegółowe informacje o repozytorium znajdziesz w Plik README repozytorium

Użycie repozytorium ma taką postać:

repo command options

Elementy opcjonalne są umieszczone w nawiasach kwadratowych []. Na przykład wiele poleceń project-list jako argument. Możesz określić project-list może mieć postać listy nazw lub ścieżek do lokalnych katalogów źródłowych projekty:

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 konkretnego polecenia Repo, w którym wskazano polecenie jako opcję:

repo help command

Na przykład poniższe polecenie powoduje wyświetlenie opisu i listy opcji dla polecenia init:

repo help init

Aby zobaczyć tylko listę dostępnych opcji polecenia, uruchom polecenie:

repo command --help

Na przykład:

repo init --help

init

repo init -u url [options]

Instaluje repozytorium w bieżącym katalogu. To polecenie tworzy .repo/ z repozytoriami Git zawierającymi kod źródłowy Repo oraz standardowych plikach manifestu Androida.

Opcje:

  • -u: podaj adres URL, z którego ma być pobierane repozytorium pliku manifestu. Wspólny plik manifestu znajduje się pod adresem https://android.googlesource.com/platform/manifest.

  • -m: wybierz plik manifestu w repozytorium. Jeśli nie ma nazwy pliku manifestu wybrana wartość domyślna to default.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 pozwoli uzyskać git fetch we wszystkich repozytoriach Git. Jeśli biegasz repo sync bez argumentów, synchronizuje pliki we wszystkich projektach.

Po uruchomieniu repo sync:

  • Jeśli projekt nigdy nie był zsynchronizowany, repo sync jest odpowiednikiem funkcji git clone wszystkie gałęzie w repozytorium zdalnym są kopiowane do repozytorium lokalnego katalogu projektu.

  • Jeśli projekt został już wcześniej zsynchronizowany, projekt repo sync jest odpowiednikiem do:

    git remote update
    git rebase origin/branch
    

    Gdzie branch to bieżący oddział płatności w lokalnym kraju katalogu projektu. Jeśli oddział lokalny nie śledzi oddziału na pilocie projekt nie zostanie zsynchronizowany.

Po udanym uruchomieniu zadania repo sync kod w określonych projektach jest aktualne i zsynchronizowane z kodem w zdalnym repozytorium.

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 przydatne, jeśli projekt jest w gałęzi tematu, ale wersja pliku manifestu jest tymczasowo potrzebny.
  • -f: synchronizuj inne projekty, nawet jeśli nie uda się zsynchronizować projektu.
  • threadcount: podziel synchronizację między wątkami: szybszego ukończenia. Zadbaj o to, aby nie przeciążyć komputera – zostaw trochę CPU zarezerwowane dla innych zadań. Aby zobaczyć liczbę dostępnych procesorów, najpierw uruchom nproc --all
  • -q: działaj dyskretnie przez pomijanie komunikatów o stanie.
  • -s: synchronizacja z dobrą kompilacją określoną przez element manifest-server w 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 przypadku określonych projektów 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 został przesłany do sprawdzenia.

Wszystkie zatwierdzenia w wybranych gałęziach są następnie przesyłane do Gerrit przez Połączenie HTTPS. Aby umożliwić przesyłanie, musisz skonfigurować hasło HTTPS autoryzacji. Aby wygenerować nową parę nazwy użytkownika i hasła do używania przez HTTPS, odwiedź Generator haseł.

Gdy Gerrit otrzymuje dane obiektu przez swój serwer, zmienia każdą z nich wprowadzić zmiany, aby weryfikatorzy mogli skomentować konkretne zatwierdzenie. Aby połączyć kilka zatwierdzeń punktu kontrolnego w jedno zatwierdzenie, użyj git rebase -i przed przesłaniem.

Jeśli uruchomisz funkcję repo upload bez argumentów, przeszukuje ona wszystkie projekty pod kątem: zmiany do przesłania.

Aby edytować zmiany po ich przesłaniu, użyj narzędzia git rebase -i lub git commit --amend, aby zaktualizować lokalne zatwierdzenia. Po wprowadzeniu zmian zakończono:

  • 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 aktualnie sprawdzoną gałąź Git, użyj flagi --current-branch (lub w skrócie --cbr).

różnice

repo diff [project-list]

Pokazuje oczekujące zmiany między zatwierdzeniem a drzewem roboczym za pomocą git diff

pobierz

repo download target change

Pobiera określoną zmianę z systemu sprawdzania i udostępnia ją w lokalnym katalogu roboczym projektu.

Aby pobrać na przykład plik zmień 23823 na Katalog platform/build:

repo download platform/build 23823

Uruchomienie repo sync spowoduje usunięcie wszystkich zatwierdzeń pobranych za pomocą repo download. Lub Ty może 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. Poniższe dodatkowe zmienne środowiskowe zostały udostępnione przez program repo forall:

  • REPO_PROJECT ma unikalną nazwę projektu.
  • REPO_PATH to ścieżka względem katalogu głównego klienta.
  • REPO_REMOTE to nazwa systemu zdalnego z pliku manifestu.
  • REPO_LREV to nazwa wersji z pliku manifestu przetłumaczona na język lokalnej gałęzi śledzenia. Użyj tej zmiennej, jeśli musisz przekazać plik manifestu do lokalnego polecenia Git.
  • REPO_RREV to 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 sprawdzane przez /bin/sh i wszystkie argumenty po nim przekazywane jako pozycjonująca powłoka .
  • -p: wyświetlaj nagłówki projektu przed danymi wyjściowymi określonego polecenia. To jest osiągnięto dzięki powiązaniom potoków ze strumieniami stdin, stdout i sterr polecenia oraz podawanie wszystkich danych wyjściowych w ciągły strumień, który jest wyświetlany na pojedynczym stronie .
  • -v: pokazuje komunikaty, które polecenie zapisuje w stderr.

przytnij

repo prune [project-list]

Przycina (usuwa) tematy, które zostały już scalone.

rozpocznij

repo start branch-name [project-list]

Rozpoczyna nową gałąź do programowania, zaczynając od wersji określonej w pliku manifestu.

Argument BRANCH_NAME zawiera krótki opis zmiany, którą wnosisz w projektach. Jeśli jej nie znasz, spróbuj użyć nazwy default

Argument project-list określa, które projekty uczestniczą w tym temacie gałąź.

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ępują różnice między tymi 3 stanami.

Aby wyświetlić tylko stan bieżącej gałęzi, uruchom polecenie repo status .. Stan wyświetlane są informacje według projektu. W przypadku każdego pliku w projekcie znajduje się dwuliterowy kod za pomocą kodu.

W pierwszej kolumnie wielka litera wskazuje, czym różni się obszar przejściowy od ostatniego stanu zatwierdzenia.

List Znaczenie Opis
- Bez zmian Ta sama w elemencie HEAD i w indeksie
A Dodano Brak w sekcji HEAD, w indeksie
M Data modyfikacji W elemencie HEAD, zmodyfikowano 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 elementem HEAD a indeksem; rozwiązanie wymagane

W drugiej kolumnie mała litera wskazuje, czym różni się katalog roboczy od indeksu.

List 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ł uruchomiony na początku sesji. Aby odzyskać konto, wejdź na stronę ustaw identyfikator zatwierdzenia, uruchom nową gałąź i scal ją.