-q –liniște
liniște, suprima mesajele de feedback.
–progress –no-progress
starea progresului este raportată în fluxul de eroare standardîn mod implicit atunci când este atașat la un terminal, cu excepția cazului în care este specificat--quiet. Acest steag permite raportarea progresului chiar dacă nu este atașat la un terminal, indiferent de --quiet.
-f –force
la comutarea ramurilor, continuați chiar dacă indicele sau arborele de lucru diferă deHEAD. Acest lucru este folosit pentru a aruncaschimbări locale.
când verificați căile din index, nu eșuați la intrările nemergate; în schimb, intrările nemergate sunt ignorate.
–al nostru –al lor
când verificați căile din index, verificați etapa #2(a noastră) sau #3 (a lor) pentru căile nemergate.
rețineți că în timpul git rebase și git pull --rebase, al nostru andtheirs pot apărea schimbate; --ours dă versiunea dinramura modificările sunt rebasate pe, în timp ce --theirs dă versiunea din ramura care deține munca dvs. care este rebasată.
Acest lucru se datorează faptului cărebase este utilizat într-un flux de lucru care tratează istoria de la distanță ca cea canonică partajată și tratează munca făcută pe ramura pe care o rebazați ca lucrare terță parte tobe integrat și vă asumați temporar rolul de păstrător al istoriei canonice în timpul rebazei. Ca deținător al istoriei canonice, trebuie să vizualizați istoricul de la distanță ca ours (adică „istoria noastră canonică comună”), în timp ce ceea ce ați făcut pe ramura laterală ca theirs (adică. „munca unui colaborator pe partea de susdin ea”).
-b<new_branch>
creați o nouă ramură numită<new_branch> și porniți-o la<start_point>; consultați git-branch pentru detalii.
-B <new_branch> -t –track
când creați o nouă ramură, configurați configurația „upstream”. A se vedea”–track ” în Git-branch pentru detalii.
dacă nu este dată opțiunea-b, numele noii sucursale va fi preluat din ramura de urmărire la distanță, analizând partea locală a refspec configurată pentru telecomanda corespunzătoare și apoi stripând partea inițială până la „*”.Acest lucru ne-ar spune să folosim hack ca ramură locală atunci când branchingoff de origin/hack (sau remotes/origin/hack, sau chiarrefs/remotes/origin/hack). Dacă numele dat nu are slash sau cele de mai susghicirea are ca rezultat un nume gol, ghicitul este anulat. Puteți da implicit un nume cu -b într-un astfel de caz.
–no-track
nu configurați configurația „upstream”, chiar dacă variabila de configurarebranch.autoSetupMerge este adevărată.
–guess –no-guess
dacă <branch> nu este găsit, dar există o ramură de urmărire într-o singură telecomandă (numiți-o <remote>) cu numele amatching, tratați ca echivalent cu
$ git checkout -b <branch> --track <remote>/<branch>
dacă ramura există în mai multe telecomenzi și una dintre ele este denumită de checkout.defaultRemote variabilă de configurare, vom folosi asta în scopul dezambiguizării, chiar dacă <branch> nu este unică pe toate telecomenzile. Set-l deget de la picior.g. checkout.defaultRemote=origin pentru a verifica întotdeauna remotebranches de acolo dacă<branch> este ambiguu, dar există pe theorigin remote. A se vedea, de asemenea, checkout.defaultRemote ingit-config.
--guess este comportamentul implicit. Utilizați --no-guess pentru a-l dezactiva.
comportamentul implicit poate fi setat princheckout.guess configurationvariable.
-L
creați reflogul noii sucursale; a se vedea git-branch fordetails.
-d-detașați
Mai degrabă decât să verificați o ramură pentru a lucra la ea, verificați acommit pentru inspecție și experimente aruncabile.Acesta este comportamentul implicit al git checkout <commit>când<commit> nu este un nume de ramură. Consultați secțiunea” cap detașat ” de mai jos pentru detalii.
–orphan<new_branch>
creați o nouă ramură orfană, numită<new_branch>, a pornit de la<start_point> și treceți la ea. Primul angajament făcut pe această ramură nouă nu va avea părinți și va fi rădăcina unei noi istorii total deconectate de toate celelalte ramuri și comitete.
indicele și arborele de lucru sunt ajustate ca și cum ați fi rulat anteriorgit checkout <start_point>. Acest lucru vă permite să începeți o nouă istoriecare înregistrează un set de căi similare cu <start_point> rulând cu ușurințăgit commit -a pentru a face rădăcina să se angajeze.
Acest lucru poate fi util atunci când doriți să publicați arborele dintr-un commitwithout expunând istoricul său complet. S-ar putea să doriți să faceți acest lucru pentru a publicao ramură open source a unui proiect al cărui arbore actual este „curat”, dar al cărui istoric complet conține biți de cod proprii sau grevați în alt mod.
Dacă doriți să începeți un istoric deconectat care să înregistreze un set de căi care este total diferit de cel al<start_point>, atunci ar trebui să curățați indexul și arborele de lucru imediat după crearea ramurii orfane rulândgit rm -rf . de la nivelul superior al arborelui de lucru.După aceea, veți fi gata să vă pregătiți noile fișiere, repopulând arborele de lucru, copiindu-le din altă parte, extragând un tarball etc.
–ignore-skip-worktree-bits
în modul de verificare rare,git checkout -- <paths> wouldupdate numai intrările potrivite cu<paths> și modele rare în$GIT_DIR/info/sparse-checkout. Această opțiune ignoră modelele rare și adaugă înapoi orice fișiere în <paths>.
-m –merge
la comutarea ramurilor,dacă aveți modificări locale la unul sau mai multe fișiere caresunt diferite între ramura curentă și ramura lacare comutați, comanda refuză să comutereramuri pentru a vă păstra modificările în context.Cu toate acestea, cu această opțiune, o îmbinare în trei direcții între ramura curentăramura, conținutul arborelui Dvs. de lucru și Noua ramificațiese face și veți fi pe noua ramură.
atunci când se întâmplă un conflict de îmbinare, intrările index pentru conflictingpaths sunt lăsate unmerged, și aveți nevoie pentru a rezolva conflictsand marca căile rezolvate cugit add (saugit rm dacă mergeshould duce la ștergerea căii).
când verificați căile din index, această opțiune vă permite să recreați îmbinarea conflictuală în căile specificate.
la comutarea ramurilor cu--merge, modificările etapizate pot fi pierdute.
–conflict=<stil>
la fel ca--merge opțiune de mai sus, dar schimbă modul în care sunt prezentate zgârcit conflictuale, suprascriemerge.conflictStyle variabilă de configurare. Valorile posibile sunt ” merge „(implicit) și” diff3″(în plus față de ceea ce este prezentat de” merge ” stil, arată conținutul original).
-p –patch
selectați interactiv zgârcit în diferența dintre<tree-ish> (sau index, dacă nespecificat) și workingtree. Zgârcit alese sunt apoi aplicate în sens invers theworking copac (și dacă un <tree-ish> a fost specificat, indicele).
aceasta înseamnă că puteți utilizagit checkout -p pentru a renunța selectiv la arborele de lucru curent. Consultați secțiunea „mod interactiv”din git-add pentru a afla cum să utilizați modul --patch.
rețineți că această opțiune utilizează în mod implicit modul fără suprapunere (consultați și--overlay) și, în prezent, nu acceptă modul suprapunere.
–ignore-other-worktrees
git checkout refuză atunci când ref dorit este deja checkedout de un alt worktree. Această opțiune o face să verifice refout-ul oricum. Cu alte cuvinte, ref poate fi deținut de mai mult de unulcopac.
–overwrite-ignore — no-overwrite-ignore
suprascrie în tăcere fișierele ignorate la comutarea ramurilor. Acesta este comportamentul implicit. Utilizați --no-overwrite-ignore pentru a aborthe operațiune atunci când noua ramură conține fișiere ignorate.
–recurse-submodules –no-recurse-submodules
folosind--recurse-submodules va actualiza conținutul tuturor activesubmodules în funcție de comiterea înregistrată în superproject. Dacă modificările locale dintr-un submodule ar fi suprascrise, verificarea va eșua dacă nu se utilizează -f. Dacă nu se utilizează nimic (sau--no-recurse-submodules), arborii de lucru submoduli nu vor fi actualizați.La fel ca git-submodule, acest lucru se va detașa HEAD ofsubmodule.
–overlay — no-overlay
în modul de suprapunere implicit, git checkout neverremoves fișiere din index sau arborele de lucru. Cândspecificând --no-overlay, fișierele care apar în arborele index andworking, dar nu în <tree-ish> sunt eliminate, pentru a le facematch <tree-ish> exact.
— pathspec-from-file=<file>
Pathspec este trecut în <file> în loc de linia de comandă args. Dacă <file> este exact - atunci se utilizează intrarea standard. Pathspecelements sunt separate prin LF sau CR / LF. Elementele Pathspec pot fi cotate așa cum este explicat pentru variabila de configurare core.quotePath(vezi git-config). A se vedea, de asemenea, --pathspec-file-nul andglobal --literal-pathspecs.
— pathspec-file-nul
numai semnificativ cu --pathspec-from-file. Elementele Pathspec sunt separate de caracterul NUL și toate celelalte caractere sunt luate literal (inclusiv linii noi și citate).
<branch>
Branch to checkout; dacă se referă la o sucursală (adică, un nume care,atunci când este prefixat cu „refs/ heads/”, este un ref valid), atunci thatbranch este verificat. În caz contrar, dacă se referă la un angajament valid, HEAD devine „detașat” și nu mai sunteți pe orice ramură (vezi mai jos pentru detalii).
ca un caz special, puteți utilizaA...Bca o comandă rapidă pentru baza themerge aAșiB dacă există exact o bază de îmbinare. Puteți lăsa cel mult unul dintre A și B, caz în care implicit este HEAD.
<new_branch>
nume pentru noua ramură.
<start_point>
numele unui commit la care să înceapă noua ramură; seegit-sucursala pentru detalii. Implicit la HEAD.
ca un caz special, puteți utiliza "A...B" ca o comandă rapidă pentru baza themerge a A și B dacă există exact o bază de îmbinare. Puteți lăsa cel mult unul dintre A și B, caz în care implicit este HEAD.
<tree-ish>
Tree la checkout de la (atunci când sunt date căi). Dacă nu este specificat,indicele va fi utilizat.
ca un caz special, puteți utiliza "A...B" ca o comandă rapidă pentru baza themerge a A și B dacă există exact o bază de îmbinare. Puteți lăsa cel mult unul dintre A și B, caz în care implicit este HEAD.
—
nu interpretați alte argumente ca opțiuni.
<pathspec>…
limitează căile afectate de operație.
pentru mai multe detalii, consultați intrarea pathspec în gitglossary.