Git-git-checkout Documentation

-q quiet quiet

Quiet, elimina i messaggi di feedback.

progress progress no no-progress

Lo stato di avanzamento viene riportato sullo standard error streamper impostazione predefinita quando è collegato a un terminale, a meno che non sia specificato--quiet. Questo flag consente la segnalazione dei progressi anche se notattached a un terminale, indipendentemente da --quiet.

– f force force

Quando si cambia ramo, procedere anche se l’indice o l’albero di lavoro differisce da HEAD. Questo è usato per buttare viacambiamenti locali.

Quando si estraggono percorsi dall’indice, non fallire su unmergedentries; invece, le voci non selezionate vengono ignorate.

ours il nostro l loro

Quando estrai i percorsi dall’indice, controlla lo stadio #2(il nostro) o #3 (il loro) per i percorsi non uniti.

si noti che durante il git rebase e git pull --rebase la nostra andtheirs può apparire scambiati; --ours la versione da thebranch le modifiche sono riassegnate su, mentre --theirs dà theversion dal ramo che contiene il vostro lavoro che è stato riassegnato.

Questo perchérebase viene utilizzato in un flusso di lavoro che tratta la cronologia remota come quella canonica condivisa e tratta il lavoro svolto sul ramo che si sta rebasing come lavoro di terze parti per essere integrato, e si sta assumendo temporaneamente il ruolo di custode della cronologia canonica durante la rebase. Come custode della storia canonica, è necessario visualizzare la cronologia da remoteas ours (cioè “la nostra storia canonica condivisa”), mentre quello che hai fatto sul tuo ramo laterale come theirs (cioè “il lavoro di un collaboratore su di esso”).

– b<new_branch >

Crea un nuovo ramo chiamato<new_branch>e avvialo da <start_point>; vedi git-branch per i dettagli.

– B <new_branch> – t track track

Quando si crea un nuovo ramo, impostare la configurazione “upstream”. Vedi” track track ” in git-branch per i dettagli.

Se non viene fornita alcuna opzione-b, il nome del nuovo ramo verrà visualizzato dal ramo di tracciamento remoto, osservando la parte locale di refspec configurata per il telecomando corrispondente e quindi rimuovendo la parte iniziale fino a “*”.Questo ci direbbe di usare hackcome ramo locale quando si dirama diorigin/hack(oremotes/origin/hack, o ancherefs/remotes/origin/hack). Se il nome dato non ha barra, o il risultato di aboveguessing in un nome vuoto, la supposizione viene interrotta. Puoi dare esplicitamente un nome con-b in tal caso.

no no-track

Non impostare la configurazione “upstream”, anche se la variabile di configurazionebranch.autoSetupMerge è true.

–indovinare –no-guess

Se <branch> ma esiste un trackingbranch esattamente quello remoto (chiamata <remote>) con amatching nome, trattare come equivalente a

$ git checkout -b <branch> --track <remote>/<branch>

Se il ramo è presente in più telecomandi e uno di loro è nominato dall’ checkout.defaultRemote configurazione variabile, useremo quella per il riconoscimento, anche se il <branch> non’tunique su tutti i telecomandi. Metti la punta.g. checkout.defaultRemote=origin per controllare sempre remotebranches da lì se <branch> è ambiguo ma esiste sul telecomando di origine. Vedere anchecheckout.defaultRemote ingit-config.

--guess è il comportamento predefinito. Utilizzare --no-guess per disabilitarlo.

Il comportamento predefinito può essere impostato tramite checkout.guess configurationvariable.

– l

Crea il reflog del nuovo ramo; vedi git-branch fordetails.

-d det stacca

Piuttosto che controllare un ramo per lavorarci sopra, controlla acommit per l’ispezione e gli esperimenti scartabili.Questo è il comportamento predefinito digit checkout <commit> quando<commit> non è un nome di ramo. Vedere la sezione” TESTA STACCATA ” di seguito per i dettagli.

orphan orphan<new_branch>

Crea un nuovo ramo orfano, chiamato<new_branch>, avviato da<start_point> e passa ad esso. Il primo commit effettuato su questo nuovo ramo non avrà genitori e sarà la radice di una nuova storia totalmente disconnessa da tutti gli altri rami e commits.

L’indice e l’albero di lavoro vengono regolati come se si fosse eseguito in precedenzagit checkout <start_point>. Ciò consente di avviare una nuova cronologia che registra un insieme di percorsi simili a <start_point> eseguendo facilmentegit commit -a per eseguire il commit di root.

Questo può essere utile quando si desidera pubblicare l’albero da un commit senza esporre la sua cronologia completa. Potresti voler farlo per pubblicare un ramo open source di un progetto il cui albero corrente è “pulito”, ma la cui cronologia completa contiene bit di codice proprietari o altrimenti gravati.

Se si desidera avviare una disconnesso storia che registra una serie di pathsthat è completamente diverso da quello del <start_point>, poi si shouldclear l’indice e l’albero di lavoro subito dopo aver creato il orphanbranch eseguendo git rm -rf . dal livello superiore dell’albero di lavoro.In seguito sarai pronto a preparare i tuoi nuovi file, ripopolando l’albero di lavoro, copiandoli da altrove, estraendo un tarball, ecc.

ignore ignore-skip-worktree-bits

In modalità di checkout sparse,git checkout -- <paths>aggiornerebbe solo le voci corrispondenti a<paths>e modelli sparsi$GIT_DIR/info/sparse-checkout. Questa opzione ignora i pattern sparsi e aggiunge indietro qualsiasi file in <paths>.

-m merge merge

Quando si cambia ramo,se si hanno modifiche locali a uno o più file che sono diversi tra il ramo corrente e il ramo towhich si sta cambiando, il comando si rifiuta di switchbranches al fine di preservare le modifiche nel contesto.Tuttavia, con questa opzione, un’unione a tre vie tra il currentbranch, il contenuto dell’albero di lavoro e il nuovo branchis fatto, e sarai sul nuovo ramo.

Quando si verifica un conflitto di unione, le voci di indice per i percorsi di conflitto vengono lasciate senza fusione e è necessario risolvere i conflitti e contrassegnare i percorsi risolti congit add(ogit rm se l’unione comporta la cancellazione del percorso).

Quando si estraggono percorsi dall’indice, questa opzione consente di ricreare l’unione in conflitto nei percorsi specificati.

Quando si cambia ramo con --merge, le modifiche in scena potrebbero andare perse.

conflict conflict=<style>

Lo stesso di--merge opzione sopra, ma cambia il modo in cui vengono presentati gli hunk conflicting, sovrascrivendomerge.conflictStyle variabile di configurazione. I valori possibili sono “unisci” (predefinito) e” diff3″(in aggiunta a ciò che viene mostrato dallo stile” unisci”, mostra il contenuto originale).

-p patch patch

Seleziona interattivamente gli hunk nella differenza tra <tree-ish> (o l’indice, se non specificato) e l’albero di lavoro. Gli hunk scelti vengono quindi applicati in senso inverso all’albero di lavoro (e se è stato specificato un <tree-ish>, l’indice).

Ciò significa che è possibile utilizzaregit checkout -p per scartare selettivamente i dati dal proprio albero di lavoro corrente. Vedere la sezione “Modalità interattiva” di git-add per imparare a utilizzare la modalità--patch.

Nota che questa opzione utilizza la modalità no overlay per impostazione predefinita (vedi anche --overlay) e attualmente non supporta la modalità overlay.

ignore ignore-other-worktrees

git checkout rifiuta quando il riferimento desiderato è già controllato da un altro albero di lavoro. Questa opzione fa sì che controlli comunque il refout. In altre parole, l’arbitro può essere tenuto da più di unoalbero di lavoro.

over overwrite-ignore no no-overwrite-ignore

Sovrascrive silenziosamente i file ignorati quando si cambia ramo. Questo è il comportamento predefinito. Utilizzare --no-overwrite-ignore per interrompere l’operazione quando il nuovo ramo contiene file ignorati.

Using recurse-submodules no no-recurse-submodules

Utilizzando--recurse-submodules aggiornerà il contenuto di tutti i activesubmodules in base al commit registrato nel superproject. Se le modifiche locali in un sottomodulo verrebbero sovrascritte, il checkout fallirà a meno che non venga utilizzato-f. Se non viene utilizzato nulla (o --no-recurse-submodules), gli alberi di lavoro dei sottomoduli non verranno aggiornati.Proprio come git-submodule, questo staccheràHEAD del sottomodulo.

overlay overlay no no-overlay

Nella modalità overlay predefinita,git checkout non rimuove mai i file dall’indice o dall’albero di lavoro. Whenspecifying--no-overlay, i file che appaiono nell’albero di andworking indice, ma non in<tree-ish> vengono rimossi, per fare themmatch<tree-ish> esattamente.

path pathspec-from-file=<file>

Pathspec viene passato in <file> invece di args da riga di comando. Se<file> è esattamente - viene utilizzato lo standard input. Gli elementi Pathspecelements sono separati da LF o CR / LF. Gli elementi Pathspec possono essere quotati come spiegato per la variabile di configurazione core.quotePath (vedi git-config). Vedere anche --pathspec-file-nulandglobal--literal-pathspecs.

path pathspec-file-nul

Significativo solo con --pathspec-from-file. Gli elementi Pathspec sono separati dal carattere NUL e tutti gli altri caratteri sono presi in modo letterale (comprese le newline e le virgolette).

<branch >

Branch to checkout; se si riferisce a un branch (cioè, un nome che,quando anteposto a “refs/ heads/”, è un ref valido), allora thatbranch viene estratto. Altrimenti, se si riferisce a un validcommit, il tuo HEAD diventa “distaccato” e non sei più su nessun ramo (vedi sotto per i dettagli).

Come caso speciale, è possibile utilizzareA...Bcome scorciatoia per la base diAeB se esiste esattamente una base di unione. Puoi lasciare al massimo uno di A e B, nel qual caso il valore predefinito è HEAD.

<new_branch>

Nome per il nuovo ramo.

<start_point >

Il nome di un commit in cui avviare il nuovo ramo; seegit-branch per i dettagli. Il valore predefinito è HEAD.

Come caso speciale, è possibile utilizzare"A...B"come scorciatoia per la base diAeB se esiste esattamente una base di unione. Puoi lasciare al massimo uno di A e B, nel qual caso il valore predefinito è HEAD.

<albero-ish>

Albero da cui effettuare il checkout (quando vengono forniti i percorsi). Se non specificato, verrà utilizzato l’indice.

Come caso speciale, è possibile utilizzare"A...B"come scorciatoia per la base diAeB se esiste esattamente una base di unione. Puoi lasciare al massimo uno di A e B, nel qual caso il valore predefinito è HEAD.

Non interpretare altri argomenti come opzioni.<pathspec >…

Limita i percorsi interessati dall’operazione.

Per maggiori dettagli, vedere la voce pathspec in gitglossary.

Related Posts

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *