– q — quiet
Quiet, feedbackberichten onderdrukken.
— progress — no-progress
voortgangsstatus wordt standaard gerapporteerd op de standaard foutenstream wanneer deze aan een terminal is gekoppeld, tenzij --quietis opgegeven. Deze vlag maakt voortgangsrapportage mogelijk, zelfs als deze niet is gekoppeld aan een terminal, ongeacht --quiet.
– f — force
bij het wisselen van branches, ga door, zelfs als de index of de Working tree verschilt van HEAD. Dit wordt gebruikt om lokale veranderingen weg te gooien.
bij het uitchecken van paden uit de index, niet falen op unmergedentries; in plaats daarvan, unmerged entries worden genegeerd.
–ours –theirs
bij het uitchecken van paden uit de index, check out stage #2(ours) of #3 (theirs) voor niet-samengevoegde paden.
merk op dat tijdens git rebase en git pull --rebase, onze en theirs kunnen worden verwisseld; --ours geeft de versie van thebranch de wijzigingen worden gerebased op, terwijl --theirs geeft de versie van de branch die houdt je werk vast dat wordt gerebased.
Dit komt omdat rebase wordt gebruikt in een workflow die de geschiedenis op de remote behandelt als de gedeelde canonieke, en het werk dat wordt gedaan op de branch die u rebasen behandelt als het werk van derden dat moet worden geïntegreerd, en u tijdelijk de rol van beheerder van de canonieke geschiedenis op zich neemt tijdens de rebase. Als de houder van de canonieke geschiedenis, moet u de geschiedenis van de remoteas ours (dwz “onze gedeelde canonieke geschiedenis”), terwijl wat u didon uw zijtak als theirs (dwz. “one contributor’ s work on topof it”).
– b <new_branch>
Maak een nieuwe branch aan met de naam <new_branch> en start het op<start_point>; zie git-branch voor details.
– B <new_branch> -t –track
bij het maken van een nieuwe branch, stel” upstream ” configuratie in. Zie “–track ” in git-branch voor details.
als geen-b optie is gegeven, zal de naam van de nieuwe branch worden afgeleid van de remote-tracking branch, door te kijken naar het lokale deel van de refspec geconfigureerd voor de overeenkomstige remote, en dan het initiële deel te strippen tot de “*”.Dit zou ons vertellen om hack als de lokale branch te gebruiken bij het aftasten van origin/hack (of remotes/origin/hack, of zelfsrefs/remotes/origin/hack). Als de opgegeven naam geen schuine streep heeft, of als de bovenbeguessing resulteert in een lege naam, wordt het raden afgebroken. In zo ‘ n geval kunt u expliciet een naam opgeven met -b.
–no-track
stel de configuratie “upstream” niet in, zelfs niet als de configuratie variabelebranch.autoSetupMerge true is.
–denk –no-raden
Als <branch> is niet gevonden, maar er bestaat een trackingbranch in precies één afstandsbediening (noem het <remote>) met amatching naam, behandelen als gelijkwaardig met
$ git checkout -b <branch> --track <remote>/<branch>
Als de tak bestaat in meerdere afstandsbedieningen en één van hen is genoemd door checkout.defaultRemote configuratie variabele gebruiken we thatone voor de toepassing van doorverwijspagina, zelfs als de <branch> is’tunique over alle afstandsbedieningen. Zet het in de teen.g. checkout.defaultRemote=origin om remotebranches vanaf daar altijd uit te checken als <branch> dubbelzinnig is, maar bestaat op de originele remote. Zie ook checkout.defaultRemote ingit-config.
--guess is het standaardgedrag. Gebruik --no-guess om het uit te schakelen.
het standaardgedrag kan worden ingesteld via decheckout.guess configuratievariabel.
– l
maak de reflog van de nieuwe branch aan; zie git-branch voor details.
– d –detach
in plaats van het uitchecken van een branch om eraan te werken, moet u accommit controleren voor inspectie en verwijderbare experimenten.Dit is het standaardgedrag van git checkout <commit> wanneer<commit> geen branchnaam is. Zie de sectie” losstaande kop ” hieronder voor details.
— orphan <new_branch>
Maak een nieuwe verweesde tak aan, genaamd <new_branch>, gestart vanuit<start_point> en schakel er naar Over. De eerste commit gemaakt op deze nieuwe branch zal geen ouders hebben en het zal de root zijn van een newhistory die volledig losgekoppeld is van alle andere branches en commits.
de index en de werkboom worden aangepast alsof u eerdergit checkout <start_point>had uitgevoerd. Hiermee kunt u een nieuwe historiestartendat een set paden registreert die vergelijkbaar zijn met <start_point> door eenvoudiggit commit -a te draaien om de root commit te maken.
dit kan handig zijn wanneer u de boomstructuur van een commit wilt publiceren zonder de volledige geschiedenis ervan bloot te leggen. Je zou dit kunnen doen om een open source tak van een project te publiceren waarvan de huidige boomstructuur “schoon” is, maar waarvan de volledige geschiedenis propriëtaire of anderszins bezwaarde stukjes code bevat.
Als u een verbroken geschiedenis wilt starten die een reeks paden registreert die totaal anders is dan die van <start_point>, dan moet u de index en de werkstructuur verwijderen direct na het aanmaken van de orphanbranch door git rm -rf . uit het bovenste niveau van de werkstructuur te draaien.Daarna ben je klaar om je nieuwe bestanden voor te bereiden, de Working tree opnieuw te bevolken, door ze van elders te kopiëren, een tarball te extraheren, enz.
— ignore-skip-worktree-bits
In sparse checkout mode, git checkout -- <paths> zou alleen items die overeenkomen met <paths> en sparse patternsin $GIT_DIR/info/sparse-checkoutbijwerken. Deze optie ontbrandt de schaarse patronen en voegt alle bestanden terug in <paths>.
– m –merge
bij het wisselen van branches,als je lokale wijzigingen hebt in een of meer bestanden die verschillen tussen de huidige branch en de branch die je wisselt, weigert het commando om van branch te wisselen om je wijzigingen in context te behouden.Echter, met deze optie, een Drieweg merge tussen de huidige Branch, uw werk boom inhoud, en de nieuwe branchis gedaan, en je zult op de nieuwe branch.
wanneer een mergeconflict optreedt, worden de index-items voor conflicterende paden niet samengevoegd, en u moet de conflicten oplossen en de opgeloste paden markeren met git add (of git rm als de Merge moet resulteren in het verwijderen van het pad).
bij het uitchecken van paden uit de index kunt u met deze optie de conflicterende samenvoeging in de opgegeven paden opnieuw maken.
bij het wisselen van branches met --merge kunnen gestage wijzigingen verloren gaan.
–conflict=<style>
hetzelfde als --merge optie hierboven, maar verandert de manier waarop de conflicterende hunks worden gepresenteerd, waarbij demerge.conflictStyle configuratie variabele wordt vervangen. Mogelijke waarden zijn” merge “(standaard) en” diff3″(in aanvulling op wat wordt getoond door” merge ” stijl, toont de oorspronkelijke inhoud).
-p –patch
interactief hunks selecteren in het verschil tussen de<tree-ish> (of de index, indien niet gespecificeerd) en de werkboom. De gekozen hunks worden dan omgekeerd toegepast op de Working tree (en als een <tree-ish> werd gespecificeerd, de index).
Dit betekent dat u git checkout -p kunt gebruiken om selectief verwijderingen van uw huidige werkboom te verwijderen. Zie de”Interactive Mode”sectie van git-add om te leren hoe de --patch modus te bedienen.
merk op dat deze optie standaard de no overlay-modus gebruikt (zie ook--overlay), en momenteel geen overlay-modus ondersteunt.
— ignore-other-worktrees
git checkout weigert wanneer de gewenste ref al door een andere worktree is uitgecheckt. Deze optie maakt het controleren van de refout toch. Met andere woorden, de ref kan worden gehouden door meer dan eenwerkboom.
— overwrite-ignore –no-overwrite-ignore
geruisloos genegeerd bestanden overschrijven bij het wisselen van branches. Dit is het standaard gedrag. Gebruik --no-overwrite-ignore om de operatie af te breken wanneer de nieuwe branch genegeerd bestanden bevat.
–recurse-submodules — no-recurse-submodules
met --recurse-submodules zal de inhoud van alle activesubmodules worden bijgewerkt volgens de commit die is opgenomen in het superproject. Iflocale wijzigingen in een submodule zouden worden overschreven de checkOut zal mislukken tenzij -f wordt gebruikt. Als er niets (of --no-recurse-submodules)wordt gebruikt, zullen submodules die werken niet worden bijgewerkt.Net als git-submodule, zal dit HEAD van de submodule losmaken.
–overlay — no-overlay
in de standaard overlay-modus, git checkout verwijdert bestanden nooit uit de index of de werkstructuur. Wanneer u --no-overlay specificeert, worden bestanden die in de index-en werkstructuur voorkomen, maar niet in <tree-ish> verwijderd, om de match <tree-ish> exact te maken.
–pathspec-from-file=<file>
Pathspec wordt doorgegeven in <file> in plaats van commandline argumenten. Als<file> precies - is, wordt standaard invoer gebruikt. Pathspecelements worden gescheiden door LF of CR/LF. Pathspec elementen kunnen worden overgedragen zoals uitgelegd voor de configuratie variabele core.quotePath(zie git-config). Zie ook --pathspec-file-nul englobal --literal-pathspecs.
–pathspec-file-nul
alleen zinvol met --pathspec-from-file. Pathspec-elementen worden gescheiden door NUL-karakter en alle andere karakters worden letterlijk genomen (inclusief newlines en aanhalingstekens).
<branch>
Branch to checkout; als het verwijst naar een branch (dat wil zeggen, een naam die,wanneer toegevoegd met” refs/heads/”, een geldige ref is), dan wordt thatbranch uitgecheckt. Anders, als het verwijst naar een validcommit, wordt uw HEAD “losgekoppeld” en bent u niet langer op elke tak (zie hieronder voor details).
als een speciaal geval kunt u A...B gebruiken als een snelkoppeling voor de samenvoeg basis van A en B als er precies één samenvoeg basis is. U kunt maximaal één van A en B opgeven, in welk geval het standaard HEADis.
<new_branch>
naam voor de nieuwe tak.
<start_point>
de naam van een commit waarop de nieuwe branch moet worden gestart; ziegit-branch voor details. Standaard HEAD.
als een speciaal geval kunt u "A...B" gebruiken als een snelkoppeling voor de samenvoeg basis van A en B als er precies één samenvoeg basis is. U kunt maximaal één van A en B opgeven, in welk geval het standaard HEADis.
<boom-achtig>
boom om uit te checken (wanneer paden worden opgegeven). Indien niet opgegeven, wordt de index gebruikt.
als een speciaal geval kunt u "A...B" gebruiken als een snelkoppeling voor de samenvoeg basis van A en B als er precies één samenvoeg basis is. U kunt maximaal één van A en B opgeven, in welk geval het standaard HEADis.
—
interpreteer geen argumenten meer als opties.
<pathspec>…
beperkt de paden die door de operatie worden beïnvloed.
voor meer details, zie het pathspec-item in gitglossary.