Opis poleceń repozytorium

Repo uzupełnia Git, upraszczając pracę w wielu repozytoriach. Zobacz Narzędzia kontroli źródła o wyjaśnienie relacji między repo i Git. Więcej informacji na temat Repo, zobacz Repo README .

Wykorzystanie repo przybiera następującą formę:

repo command options

Elementy opcjonalne są pokazane w nawiasach [ ]. Na przykład, wiele poleceń wziąć project-list jako argument. Można określić project-list jako listy nazw lub listy ścieżek dostępu do lokalnych katalogów źródłowych projektów:

repo sync [project0 project1 ... projectn]
repo sync [/path/to/project0 ... /path/to/projectn]

Wsparcie

Ta strona przedstawia jedynie kluczowe opcje. Zobacz pomoc wiersza poleceń, aby uzyskać szczegółowe informacje. Po zainstalowaniu Repo możesz znaleźć najnowszą dokumentację, zaczynając od podsumowania wszystkich poleceń, uruchamiając:

repo help

Możesz zobaczyć szczegółowe informacje o dowolnym poleceniu, uruchamiając to w drzewie Repo:

repo help command

Na przykład, następujące polecenie daje opis i listę opcji dla init argument Repo, który inicjuje Repo w bieżącym katalogu. (Patrz init, aby poznać szczegóły.)

repo help init

Lub, aby zobaczyć tylko listę dostępnych opcji, uruchom:

repo command --help
np
repo init --help

w tym

repo init -u url [options]

Instaluje repozytorium w bieżącym katalogu. Stwarza to .repo/ katalog z repozytoriów Git kodu źródłowego repo i standardowych Android oczywistych plików.

Opcje:

  • -u : Określ adres URL, z którego można pobierać oczywisty repozytorium. Wspólny manifest znajduje się w https://android.googlesource.com/platform/manifest .
  • -m : Wybierz plik manifestu w repozytorium. Jeżeli nie zostanie wybrany żaden oczywisty nazwa, domyślnie jest default.xml .
  • -b : Określ wersję, czyli konkretny manifest-branch .

Uwaga: W przypadku wszystkich pozostałych poleceń Repo, bieżący katalog roboczy musi być albo katalogu nadrzędnego .repo/ lub podkatalogu katalogu nadrzędnego.

synchronizacja

repo sync [project-list]

Pliki do pobrania nowe zmiany i aktualizuje pliki pracę w środowisku lokalnym, w zasadzie realizacji git fetch we wszystkich repozytoriów Git. Jeśli prowadzisz repo sync bez argumentów, to synchronizuje pliki dla wszystkich projektów.

Po uruchomieniu repo sync , to co się dzieje:

  • Jeśli projekt nie został zsynchronizowany, następnie repo sync jest równoważna git clone . Wszystkie gałęzie w zdalnym repozytorium są kopiowane do lokalnego katalogu projektu.

  • Jeśli projekt został zsynchronizowany wcześniej, wtedy repo sync jest równoznaczne z:

    git remote update
    git rebase origin/branch
    

    gdzie branch jest obecnie sprawdzana-out oddział w lokalnym katalogu projektu. Jeśli oddział lokalny nie śledzi oddziału w repozytorium zdalnym, dla projektu nie nastąpi synchronizacja.

  • Jeśli Git zmieniają bazę wyniki operacji w konflikty scalania, użyj polecenia Git (np git rebase --continue ) do rozwiązywania konfliktów.

Po pomyślnym przebiegu repo sync , kod w określonych projektów jest aktualne i zsynchronizowane z kodu w zdalnym repozytorium.

Oto kluczowe opcje. Zobacz repo help sync na więcej:

  • -c : Fetch tylko bieżącą oczywistego oddział z serwera.

  • -d : Projekty przełączników podano powrotem do oczywistego rewizji. Jest to przydatne, jeśli projekt znajduje się obecnie w gałęzi tematu, ale wersja manifestu jest tymczasowo potrzebna.

  • -f : Kontynuować synchronizowania innych projektów, nawet jeśli projekt nie zsynchronizowane.

  • -j threadcount : Split synchronizacji całej nici do szybszego zakończenia. Upewnij się, że nie przeciążysz swojej maszyny - zostaw trochę procesora zarezerwowanego dla innych zadań. Aby zobaczyć liczbę dostępnych procesorów, pierwszego uruchomienia: nproc --all

  • -q : Run cicho tłumiąc komunikaty stanu.

  • -s : Sync do znanej dobrej kompilacji określony przez manifest-server elementem obecnej manifeście.

Przekazać plik

repo upload [project-list]

W przypadku określonych projektów Repo porównuje oddziały lokalne z oddziałami zdalnymi zaktualizowanymi podczas ostatniej synchronizacji repozytorium. Repo prosi o wybranie jednej lub więcej gałęzi, które nie zostały przesłane do przeglądu.

Wszystkie zatwierdzenia w wybranych gałęziach są następnie przesyłane do Gerrita przez połączenie HTTPS. Aby włączyć autoryzację przesyłania, musisz skonfigurować hasło HTTPS. Odwiedź Password Generator wygenerować nową parę login / hasło do korzystania z protokołu HTTPS.

Kiedy Gerrit otrzymuje dane obiektu na swoim serwerze, zamienia każde zatwierdzenie w zmianę, dzięki czemu recenzenci mogą komentować określone zatwierdzenie. Aby połączyć kilka zobowiązuje punktów kontrolnych w jeden commit, użyj git rebase -i przed uruchomieniem przesyłania.

Jeśli prowadzisz repo upload bez argumentów, przeszukuje wszystkie projekty zmian do przesłania.

Aby edytować zmian po ich przesłanych użyć narzędzia takie jak git rebase -i lub git commit --amend zaktualizować lokalne zobowiązuje. Po zakończeniu edycji:

  • Sprawdź, czy zaktualizowana gałąź jest aktualnie wyrejestrowaną gałęzią.
  • Dla każdego zatwierdzenia w serii wprowadź 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 replacments
    # 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 wyrejestrowany Git oddziału, należy użyć flagi --current-branch (lub --cbr w skrócie).

różnica

repo diff [project-list]

Pokazy wybitnych zmian pomiędzy popełnić i drzewo pracuje używając git diff .

pobieranie

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 w katalogu platforma / build:

repo download platform/build 23823

Uruchamianie repo sync usuwa wszelkie, popełnia pobierane z repo download . Albo można sprawdzić za pomocą pilota zdalnego oddział git checkout m/master .

Uwaga: Są opóźnienia replikacji do wszystkich serwerów na całym świecie, więc istnieje niewielkie opóźnienie między mirroring, gdy zmiana jest widoczna w internecie w Gerrit i kiedy repo download można znaleźć zmiany dla wszystkich użytkowników.

dla wszystkich

repo forall [project-list] -c command

Wykonuje podane polecenie powłoki w każdym projekcie. Następujące dodatkowe zmienne środowiskowe są udostępniane przez repo forall :

  • REPO_PROJECT ustawiony jest na unikalnej nazwy projektu.

  • REPO_PATH jest względna ścieżka do katalogu głównego klienta.

  • REPO_REMOTE to nazwa systemu zdalnego z manifestu.

  • REPO_LREV to nazwa rewizji z manifestu, przetłumaczone do lokalnego oddziału śledzenia. Użyj tego, jeśli chcesz przekazać wersję manifestu do lokalnie wykonywanego polecenia Git.

  • REPO_RREV to nazwa rewizji z manifestu, dokładnie tak, jak napisano w manifeście.

Opcje:

  • -c : Polecenie i argumenty do wykonania. Polecenie jest oceniana przez /bin/sh , a wszelkie argumenty po nim są przepuszczane przez powłoki jako parametrów pozycyjnych.

  • -p : nagłówki Pokaż projektu przed wyjściem określonego polecenia. Osiąga się to poprzez powiązanie potoków ze strumieniami stdin, stdout i sterr polecenia oraz potokowanie wszystkich danych wyjściowych w ciągły strumień, który jest wyświetlany w pojedynczej sesji pagera.

  • -v : Pokaż wiadomości polecenia pisze na stderr.

suszona śliwka

repo prune [project-list]

Przycina (usuwa) tematy, które są już połączone.

początek

repo start
branch-name [project-list]

Rozpoczyna nową gałąź do rozwoju, zaczynając od wersji określonej w manifeście.

BRANCH_NAME argumentem zawiera krótki opis zmian starasz się wprowadzić do projektów. Jeśli nie wiesz, należy rozważyć użycie nazwy default .

The project-list określa argument projekty biorące udział w tym temacie oddziału.

Uwaga: (.) Okres A jest skrótem dla projektu w bieżącym katalogu roboczym.

status

repo status [project-list]

Porównuje drzewo robocze z obszarem pomostowym (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 sprawdzić stan tylko bieżącej gałęzi, uruchom repo status . . Informacje o stanie są wyświetlane według projektu. Dla każdego pliku w projekcie używany jest dwuliterowy kod.

W pierwszej kolumnie wielka litera wskazuje, jak obszar przemieszczania 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, nie w indeksie
r Zmieniono nazwę Nie w HEAD, ścieżka zmieniona w indeksie
C Skopiowane Nie w HEAD, skopiowane z innego w indeksie
T Zmieniono tryb Ta sama treść w HEAD i index, zmieniony tryb
U Niescalone Konflikt między HEAD a indeksem; wymagana rozdzielczość

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

List Oznaczający Opis
- Nowy/nieznany Nie w indeksie, w drzewie pracy
m Zmodyfikowany W indeksie, w drzewie roboczym, zmodyfikowany
D Usunięto W indeksie, a nie w drzewie pracy

Obsługa błędów repo

git reflog

repo start branch-name

git merge commit-id

repo upload .

Błąd repo: error: no branches ready for upload pojawia się, gdy komenda repo start nie został uruchomiony na początku sesji. Aby odzyskać, możesz sprawdzić identyfikator zatwierdzenia, uruchomić nową gałąź, a następnie ją scalić.