– q –quiet
cicho, wyłącza komunikaty zwrotne.
–progress –no-progress
Status postępu jest raportowany dla standardowego błędu streamby default, gdy jest on podłączony do terminala, chyba że podano --quiet. Flaga ta umożliwia raportowanie postępu nawet jeśli nie jest dołączona do terminala, niezależnie od --quiet.
– F –force
podczas przełączania gałęzi postępuj, nawet jeśli indeks lub drzewo różni się od HEAD. Służy to do rzucania zmian w poszczególnych miejscach.
podczas sprawdzania ścieżek z indeksu, nie zawiedzie się przy niezintegrowanych obiektach; zamiast tego niezintegrowane wpisy są ignorowane.
–ours –theirs
podczas sprawdzania ścieżek z indeksu, sprawdź etap #2(Nasz) lub #3 (ich) dla ścieżek niezmergowanych.
zauważ, że podczasgit rebase Igit pull --rebase, Nasze i ich mogą pojawić się zamienione;--ours podaje wersję z gałęzi, na której zmiany są zmieniane, podczas gdy--theirs daje Oddzial z Brancha ktory trzyma prace ktora jest rebazowana.
dzieje się tak dlatego, żerebase jest używany w obiegu pracy, który traktuje historię na zdalnym jako wspólną kanoniczną, a pracę wykonaną na gałęzi, którą zmieniasz, traktuje jako pracę innej firmy, która zostanie zintegrowana, a Ty tymczasowo przejmujesz rolę właściciela historii kanonicznej podczas rebazy. Jako opiekun historii kanonicznej, musisz przeglądać historię z remoteas ours (tj.” nasza wspólna historia kanoniczna”), podczas gdy to, co zrobiłeś w swojej gałęzi bocznej jako theirs (tj. „praca jednego współpracownika nad nim”).
-B<new_branch>
Utwórz nową gałąź o nazwie<new_branch> I uruchom ją w<start_point>; zobacz Git-branch po szczegóły.
– B <new_branch>- t –track
podczas tworzenia nowej gałęzi należy skonfigurować konfigurację „upstream”. Zobacz” — track ” w git-branch po szczegóły.
Jeśli nie podano opcji-b, nazwa nowej gałęzi zostanie pobrana z gałęzi Remote-tracking, patrząc na lokalną część refspec skonfigurowaną dla odpowiedniego pilota, a następnie usuwając początkową część do „*”.Oznacza to, że powinniśmy używać hack jako lokalnej gałęzi podczas rozgałęziania origin/hack (lub remotes/origin/hack, lub nawetrefs/remotes/origin/hack). Jeśli podana nazwa nie ma ukośnika lub powyższy znak powoduje, że nazwa jest pusta, zgadywanie jest przerywane. W takim przypadku możesz domyślnie podać nazwę za pomocą -b.
–no-track
nie Konfiguruj konfiguracji „upstream”, nawet jeśli zmienna konfiguracyjnabranch.autoSetupMerge ma wartość true.
–guess –no-guess
Jeśli <branch> nie został znaleziony, ale w dokładnie jednym zdalnym (nazwij go <remote>) o amatorskiej nazwie, traktuj jako odpowiednik
$ git checkout -b <branch> --track <remote>/<branch>
Jeśli gałąź istnieje w wielu pilotach, a jeden z nich jest nazwany przez checkout.defaultRemote zmienna konfiguracyjna, użyjemy tej jednej do celów disambiguacji, nawet jeśli <branch> nie jesttunique we wszystkich pilotach. Ustaw palec u nogi.g. checkout.defaultRemote=origin aby zawsze checkout remotebranches stamtąd, jeśli <branch> jest niejednoznaczny, ale istnieje na theorigin remote. Zobacz też checkout.defaultRemote ingit-config.
--guess jest zachowaniem domyślnym. Użyj --no-guess, aby go wyłączyć.
domyślne zachowanie można ustawić za pomocą konfiguracjicheckout.guess zmienna.
– L
tworzy reflog nowej gałęzi; zobacz fordetails git-branch.
– D –odłącz
zamiast sprawdzać gałąź, aby nad nią pracować, sprawdź kommit do inspekcji i eksperymentów do odrzucenia.Jest to domyślne zachowaniegit checkout <commit>, gdy<commit> nie jest nazwą gałęzi. Zobacz sekcję” odłączana Głowica ” poniżej, aby uzyskać szczegółowe informacje.
–orphan<new_branch>
Utwórz nową gałąź osieroconą o nazwie<new_branch>, rozpoczętą od<start_point> I Przełącz na nią. Pierwszy commit zrobiony na tej nowej gałęzi nie będzie miał rodziców i będzie korzeniem nowej historii całkowicie odłączonej od wszystkich innych gałęzi i commitów.
indeks i drzewo robocze są dostosowane tak, jakbyś wcześniej uruchomiłgit checkout <start_point>. Pozwala to na rozpoczęcie nowej historii, która rejestruje zestaw ścieżek podobnych do <start_point>poprzez łatwe uruchomieniegit commit -a, aby dokonać root commit.
może to być użyteczne, gdy chcesz opublikować drzewo z commit bez ujawniania jego pełnej historii. Możesz to zrobić, aby opublikować gałąź open source projektu, którego obecne drzewo jest „czyste”, ale którego pełna historia zawiera zastrzeżone lub w inny sposób obciążone bity kodu.
Jeśli chcesz rozpocząć rozłączoną historię, która rejestruje zestaw ścieżek, które są zupełnie inne niż te z<start_point>, powinieneś wyczyścić indeks i drzewo robocze zaraz po utworzeniu orphanbrancha, uruchamiającgit rm -rf . z górnego poziomu drzewa roboczego.Następnie będziesz gotowy do przygotowania nowych plików, ponownego wypełnienia drzewa roboczego, przez skopiowanie ich z innego miejsca, wyodrębnienie tarballa itp.
–ignore-skip-worktree-bits
w trybie oszczędnej kasy,git checkout -- <paths> będzie dodawać tylko wpisy pasujące do<paths> I rzadkie wzorce$GIT_DIR/info/sparse-checkout. Ta opcja ignoruje rzadkie wzorce i dodaje pliki w <paths>.
– m –merge
podczas przełączania gałęzi,jeśli masz lokalne modyfikacje jednego lub więcej plików, które różnią się między bieżącą gałęzią a gałęzią, którą przełączasz, polecenie odmawia przełączania gałęzi, aby zachować modyfikacje w kontekście.Jednak z tą opcją, połączenie trójdrożne między bieżącym, zawartością drzewa roboczego i nową gałęzią jest zakończone, a Ty będziesz na nowej gałęzi.
gdy dojdzie do konfliktu scalania, pozycje indeksu ścieżek konfliktowych pozostaną niezaangażowane, a ty musisz rozwiązać konflikt i oznaczyć rozwiązane ścieżki za pomocągit add(lubgit rm, jeśli połączenie spowoduje usunięcie ścieżki).
podczas sprawdzania ścieżek z indeksu ta opcja pozwala odtworzyć scalenie wywołane konfliktem w określonych ścieżkach.
przy przełączaniu gałęzi za pomocą--merge, zmiany etapowe mogą zostać utracone.
–conflict=<style>
to samo, co--merge powyższa opcja, ale zmienia sposób prezentowania elementów, nadpisującmerge.conflictStyle zmienna konfiguracyjna. Możliwe wartości to ” merge „(domyślnie) i” diff3″(oprócz tego, co jest pokazane w stylu” merge”, pokazuje oryginalną zawartość).
– p –patch
interaktywnie wybiera hunks w różnicy pomiędzy<tree-ish> (lub indeks, jeśli nie jest określony) a workingtree. Wybrane fragmenty są następnie stosowane w odwrotnej kolejności do drzewa roboczego (a jeśli podano <tree-ish>, indeks).
oznacza to, że możesz użyćgit checkout -p, aby selektywnie usunąć je z bieżącego drzewa roboczego. Zobacz sekcję „Tryb Interaktywny”w git-add, aby dowiedzieć się, jak obsługiwać tryb --patch.
zauważ, że ta opcja domyślnie używa trybu no overlay (patrz również--overlay) i obecnie nie obsługuje trybu overlay.
–ignore-other-worktrees
git checkout odmawia, gdy poszukiwany ref jest już sprawdzany przez inny worktrees. Ta opcja sprawia, że mimo to sprawdza refout. Innymi słowy, ref może być utrzymywany przez więcej niż oneworktree.
–overwrite-ignore — no-overwrite-ignore
Po cichu nadpisuje ignorowane pliki podczas przełączania gałęzi. Jest to zachowanie domyślne. Użyj --no-overwrite-ignore, aby przerwać operację, gdy nowa gałąź zawiera ignorowane pliki.
–recurse-submodules — no-recurse-submodules
użycie--recurse-submodules zaktualizuje zawartość wszystkich modułów activesubmodules zgodnie z zatwierdzeniem zarejestrowanym w superprojekcie. Iflocal modifications in a submodule would be overpised the checkoutwill fail chyba-f is used. Jeśli nic nie zostanie użyte (lub --no-recurse-submodules), podmoduły drzewa robocze nie zostaną zaktualizowane.Podobnie jak Git-submodule, spowoduje to odłączenieHEAD modułu.
–overlay — no-overlay
w domyślnym trybie overlay, git checkout nigdy nie usuwa plików z indeksu lub drzewa roboczego. Gdy --no-overlay, pliki, które pojawiają się w indeksie i drzewie pracy, ale nie w <tree-ish> są usuwane, aby je dokładnie dopasować <tree-ish>.
–pathspec-from-file=<plik>
ścieżka jest przekazywana w<file> zamiast args wiersza poleceń. Jeśli<file> jest dokładnie -, używane jest standardowe wejście. Elementy ścieżki są oddzielone przez LF lub CR / LF. Elementy Pathspec mogą być cytowane w sposób opisany dla zmiennej konfiguracyjnej core.quotePath(patrz git-config). Zobacz również--pathspec-file-nul andglobal--literal-pathspecs.
–pathspec-file-nul
ma znaczenie tylko z --pathspec-from-file. Elementy Pathspec są oddzielone znakiem NUL, a wszystkie inne znaki są zapisywane literalnie (w tym nowe linie i cudzysłowy).
<branch>
Branch to checkout; jeśli odnosi się do gałęzi (tj. nazwy, która po dodaniu „refs/ heads /” jest poprawnym refem), to Branch jest sprawdzany. W przeciwnym razie, jeśli odnosi się do validcommit, Twój HEAD staje się „odłączony” i nie jesteś już w żadnej gałęzi (patrz poniżej po szczegóły).
w specjalnym przypadku możesz użyćA...B jako skrótu do bazyA IB, jeśli istnieje dokładnie jedna baza scalania. Możesz usunąć co najwyżej jeden z A I B, w którym to przypadku domyślnie jest to HEAD.
<new_branch>
nazwa nowej gałęzi.
<start_point>
nazwa commita, przy którym ma zostać uruchomiona nowa gałąź; zobacz szczegóły w sekcji branch. Domyślnie HEAD.
w specjalnym przypadku możesz użyć"A...B" jako skrótu do bazyA IB, jeśli istnieje dokładnie jedna baza scalania. Możesz usunąć co najwyżej jeden z A I B, w którym to przypadku domyślnie jest to HEAD.
<podobne do drzewa>
drzewo do pobrania (gdy podano ścieżki). Jeśli nie podano,zostanie użyty indeks.
w specjalnym przypadku możesz użyć"A...B" jako skrótu do bazyA IB, jeśli istnieje dokładnie jedna baza scalania. Możesz usunąć co najwyżej jeden z A I B, w którym to przypadku domyślnie jest to HEAD.
—
nie interpretuje żadnych argumentów jako opcji.
<pathspec>…
ogranicza ścieżki, których dotyczy operacja.
aby uzyskać więcej informacji, zobacz wpis pathspec w gitglossary.