-q –quiet
Stille, undertrykke tilbakemeldinger meldinger.
–progress –no-progress
Fremdriftsstatus rapporteres på standardfeilstrømmen som standard når den er koblet til en terminal, med mindre--quieter angitt. Dette flagget muliggjør fremdriftsrapportering selv om den ikke er festet til en terminal, uavhengig av --quiet.
-f –force
når du bytter grener, fortsett selv om indeksen eller arbeidstreet er forskjellig fraHEAD. Dette brukes til å kaste bortlokale endringer.
når du sjekker ut baner fra indeksen, ikke mislykkes på unmergedentries; i stedet, unmerged oppføringer ignoreres.
– ours-theirs
når du sjekker ut stier fra indeksen, sjekk ut stage # 2 (vår) eller #3 (deres) for unmerged stier.
Merk at under git rebase og git pull --rebase kan våre andtheirs vises byttet; --ours gir versjonen fragranch endringene er rebased på, mens --theirs gir theversjon fra grenen som holder arbeidet ditt som blir rebased.
dette er fordirebase brukes i en arbeidsflyt som behandler thehistory på fjernkontrollen som den delte kanoniske, og behandler thework gjort på grenen du rebasing som tredjeparts arbeid tobe integrert, og du midlertidig tar rollen som thekeeper av den kanoniske historien under rebase. Som keeper ofthe canonical history, må du se historien fra fjerneas ours (dvs. «vår delte kanoniske historie»), mens hva du didon din side gren som theirs (dvs. «en bidragsyters arbeid på toppen av det»).
-b<new_branch>
Opprett en ny gren med navnet<new_branch> og start den på<start_point>; se git-grenen for detaljer.
-B<new_branch> -t –track
når du oppretter en ny gren, sett opp «oppstrøms» konfigurasjon. Se» — track » i git-grenen for detaljer.
hvis ingen -b alternativet er gitt, vil navnet på den nye grenen bli avledet fra fjernsporingsgrenen, ved å se på den lokale delen av refspec konfigurert for den tilsvarende fjernkontrollen, og deretter strippingden første delen opp til»*».Dette vil fortelle oss å bruke hack som lokal gren når branchingoff av origin/hack(ellerremotes/origin/hack, eller til og medrefs/remotes/origin/hack). Hvis det oppgitte navnet ikke har noen skråstrek, eller ovenforgjetting resulterer i et tomt navn, gjetningen blir avbrutt. Du kan eksplisitt gi et navn med -b i et slikt tilfelle.
–no-track
ikke sett opp» upstream » – konfigurasjon, selv om konfigurasjonsvariabelenbranch.autoSetupMerge er sann.
–guess –no-guess
Hvis <branch> ikke er funnet, men det finnes en trackingbranch i nøyaktig en fjernkontroll (kaller det <remote>) med amatching navn, behandle som tilsvarer
$ git checkout -b <branch> --track <remote>/<branch>
hvis grenen finnes i flere fjernkontroller og en av dem er navngitt av checkout.defaultRemote konfigurasjonsvariabel, bruker vi thatone til disambiguering, selv om <branch> ikke er unik på tvers av alle fjernkontroller. Sett den tå.g. checkout.defaultRemote=origin å alltid sjekke remotebranches derfra hvis <branch> er tvetydig, men finnes på theorigin remote. Se ogsåcheckout.defaultRemote ingit-config.
--guess er standard virkemåte. Bruk --no-guess for å deaktivere den.
standard oppførsel kan settes viacheckout.guess konfigurasjonvariable.
-L
Opprett den nye grenens reflog; se git-branch fordetails.I Stedet for å sjekke ut en gren for å jobbe med den, sjekk ut acommit for inspeksjon og kastbare eksperimenter.Dette er standard virkemåte forgit checkout <commit> når <commit> ikke er et grennavn. Se avsnittet» FRITTLIGGENDE HODE » nedenfor for detaljer.
–orphan<new_branch >
Opprett en ny foreldreløs gren, kalt <new_branch>, startet fra <start_point> og bytt til den. Den første commit gjort på thisnew gren vil ikke ha noen foreldre, og det vil være roten til en nyhistorie helt frakoblet fra alle de andre grenene ogforpliktelser.
indeksen og arbeidstreet justeres som om du tidligere hadde kjørt git checkout <start_point>. Dette lar deg starte en ny historieat registrerer et sett med baner som ligner på <start_point> ved å enkelt kjøregit commit -a for å gjøre roten forplikte.
Dette kan være nyttig når du vil publisere treet fra en commitwithout utsette sin fulle historie. Du vil kanskje gjøre dette for å publisere en åpen kildekode-gren av et prosjekt hvis nåværende tre er «rent», menhvis fulle historie inneholder proprietære eller på annen måte beheftet biter av kode.
hvis du vil starte en frakoblet historie som registrerer et sett med banersom er helt forskjellig fra den av <start_point>, bør duklar indeksen og arbeidstreet rett etter å ha opprettet orphanbranch ved å kjøre git rm -rf . fra øverste nivå av arbeidstreet.Etterpå vil du være klar til å forberede nye filer, repopulating theworking treet, ved å kopiere dem fra andre steder, trekke ut en tarball, etc.
–ignore-skip-worktree-bits
i sparsom kassemodus,git checkout -- <paths> wouldupdate bare oppføringer matchet av <paths> og sparsom patternsin $GIT_DIR/info/sparse-checkout. Dette alternativet ignorerer de sparsomme mønstrene og legger til filer i <paths>.
-m –merge
når du bytter grener, hvis du har lokale endringer i en eller flere filer somer forskjellige mellom den nåværende grenen og grenen tilsom du bytter, nekter kommandoen å bytte grener for å bevare endringene i sammenheng.Men med dette alternativet, en treveis flette mellom gjeldende gren, innholdet i arbeidstreet og den nye grenener ferdig, og du vil være på den nye grenen.
når en flettekonflikt skjer, er indeksoppføringene for konfliktbaner igjen unmerged, og du må løse konflikteneog merk de løste banene med git add (eller git rm hvis sammenslåingen skal resultere i sletting av banen).
når du sjekker ut baner fra indeksen, lar dette alternativet deg gjenskape den konfliktfylte flettingen i de angitte banene.
når du bytter grener med--merge, kan iscenesatte endringer gå tapt.
–conflict=<stil>
det samme som--merge alternativet ovenfor, men endrer måten theconflicting hunks presenteres, overstyrermerge.conflictStyle konfigurasjonsvariabel. Mulige verdier er «merge» (standard) og «diff3″(i tillegg til det som vises med» merge » – stil, viser det opprinnelige innholdet).
-p –patch
Interaktivt velg hunks i forskjellen mellom <tree-ish> (eller indeksen, hvis uspesifisert) og workingtree. De valgte hunks blir deretter brukt i omvendt tilarbeidstreet (og hvis en <tree-ish> ble angitt, er indeksen).
Dette betyr at du kan bruke git checkout -p for å selektivt forkaste det fra ditt nåværende arbeidstreet. Se Delen «Interaktiv Modus» i git-add for å lære hvordan du bruker--patch – modus.
Merk at dette alternativet bruker ingen overlay-modus som standard (se også --overlay), og støtter for øyeblikket ikke overlay-modus.
–ignore-other-worktrees
git checkout nekter når ønsket ref er allerede checkedout av en annen worktree. Dette alternativet gjør det sjekke refout uansett. Med andre ord, ref kan holdes av mer enn enworktreet.
–overwrite-ignore –no-overwrite-ignore Lydløst overskrive ignorerte filer når du bytter grener. Dette er standard virkemåte. Bruk--no-overwrite-ignorefor å avbryte operasjonen når den nye grenen inneholder ignorerte filer. –recurse-submodules –no-recurse-submodules
Bruker --recurse-submodules vil oppdatere innholdet i alle activesubmodules i henhold til commit registrert i superproject. Iflocal modifikasjoner i en submodule vil bli overskrevet checkoutwill mislykkes med mindre-f brukes. Hvis ingenting (eller --no-recurse-submodules)brukes, vil ikke undermoduler som arbeider trær bli oppdatert.Akkurat som git-submodule, vil dette løsne HEAD av thesubmodule.
–overlay –no-overlay
i standard overlay-modus,git checkout fjerner aldri filer fra indeksen eller arbeidstreet. Whenspecifying--no-overlay, filer som vises i indeksen andworking treet, men ikke i<tree-ish> fjernes, for å gjøre themmatch<tree-ish> nøyaktig.
–pathspec-from-file= <fil >
Pathspec sendes i <file> i stedet for kommandolinje args. Hvis <file> er nøyaktig - brukes standardinngang. Pathspecelements er adskilt AV LF eller CR / LF. Pathspec-elementer kan beskrives som forklart for konfigurasjonsvariabelen core.quotePath (se git-config). Se også --pathspec-file-nul ogglobal --literal-pathspecs.
–pathspec-file-nul
bare meningsfylt med --pathspec-from-file. Pathspec elementer areseparated MED NUL karakter og alle andre tegn er tattbokstavelig talt(inkludert linjeskift og sitater).
<gren >
Gren til kassen; hvis Det refererer til en gren (dvs. et navn som, når det er prepended med » refs / heads/», er en gyldig ref), blir den grenen sjekket ut. Ellers, hvis det refererer til en validcommit, blir HEAD «frittliggende» og du er ikke lenger onany gren (se nedenfor for detaljer).
som et spesielt tilfelle kan du bruke A...B som en snarvei for themerge base av A og B hvis det er nøyaktig en flettebase. Du canleave ut på det meste en av A og B, i så fall er det standard til HEAD.
<new_branch>
Navn på den nye grenen.
<start_point>
navnet på en innlegging for å starte den nye grenen; seegit-gren for detaljer. Standardinnstillingene er HEAD.
som et spesielt tilfelle kan du bruke "A...B" som en snarvei for themerge base avA ogB hvis det er nøyaktig en flettebase. Du canleave ut på det meste en av A og B, i så fall er det standard til HEAD.
<tree-ish>
Tre til kassen fra (når stier er gitt). Hvis ikke spesifisert,vil indeksen bli brukt.
som et spesielt tilfelle kan du bruke "A...B" som en snarvei for themerge base avA ogB hvis det er nøyaktig en flettebase. Du canleave ut på det meste en av A og B, i så fall er det standard til HEAD.
—
ikke tolk flere argumenter som alternativer.
<pathspec> …
Begrenser banene som påvirkes av operasjonen .
for mer informasjon, se pathspec-oppføringen i gitglossary.