git-checkout - Online nel cloud

PROGRAMMA:

NOME

git-checkout - Cambia rami o ripristina i file dell'albero di lavoro

SINOSSI

git cassa [-q] [-f] [-m] [ ]
git cassa [-q] [-f] [-m] --stacca [ ]
git cassa [-q] [-f] [-m] [--stacca]
git cassa [-q] [-f] [-m] [[-b|-B|--orfano] ] [ ]
git cassa [-f|--nostro|--loro|-m|--conflitto= ] [] [--] ...
git cassa [-p|--patch] [ ] [--] [ ...]

DESCRIZIONE

Aggiorna i file nell'albero di lavoro in modo che corrispondano alla versione nell'indice o nell'albero specificato.
Se non vengono dati percorsi, git cassa aggiornerà anche HEAD per impostare il ramo specificato come
il ramo attuale.

git cassa
Per prepararsi a lavorare su , passa ad esso aggiornando l'indice e i file
nell'albero di lavoro e puntando la TESTA al ramo. Modifiche locali al
i file nell'albero di lavoro vengono mantenuti, in modo che possano essere impegnati nel .

Se non viene trovato ma esiste un ramo di tracciamento esattamente in un telecomando
(chiamalo ) con un nome corrispondente, trattalo come equivalente a

$ git checkout -b --traccia /

potresti omettere , nel qual caso il comando degenera in "check out the
ramo corrente", che è un no-op glorificato con effetti collaterali piuttosto costosi per
mostra solo le informazioni di tracciamento, se esistenti, per il ramo corrente.

git cassa -b|-B [ ]
Se si specifica -b, viene creato un nuovo ramo come se git-ramo(1) sono stati chiamati e
poi verificato. In questo caso puoi usare le opzioni --track o --no-track, che
sarà passato a git ramo. Per comodità, --track senza -b implica branch
creazione; vedere la descrizione di --track sotto.

Se è dato -B, viene creato se non esiste; in caso contrario, viene ripristinato.
Questo è l'equivalente transazionale di

$ git branch -f [ ]
$ git checkout

vale a dire, il ramo non viene ripristinato/creato a meno che "git checkout" non abbia esito positivo.

git cassa --stacca [ ], git cassa [--stacca]
Preparati a lavorare sopra , staccando la TESTA su di essa (vedi "TESTA DISTACCATA"
sezione) e aggiornando l'indice e i file nell'albero di lavoro. Locale
le modifiche ai file nell'albero di lavoro vengono mantenute, in modo che il lavoro risultante
tree sarà lo stato registrato nel commit più le modifiche locali.

Quando il l'argomento è un nome di ramo, l'opzione --detach può essere usata per staccare
TESTA sulla punta del ramo (git checkout darei un'occhiata a quel ramo
senza staccare la TESTA).

omettendo stacca HEAD all'estremità del ramo corrente.

git cassa [-p|--patch] [ ] [--] ...
quando o --patch sono dati, git cassa effettua non è un cambiare ramo. si aggiorna
i percorsi nominati nell'albero di lavoro dal file indice o da un nome
(il più delle volte un commit). In questo caso, le opzioni -b e --track sono prive di significato e
dare uno di loro si traduce in un errore. Il l'argomento può essere usato per
specificare un albero specifico (cioè commit, tag o albero) per aggiornare l'indice per il
percorsi dati prima di aggiornare l'albero di lavoro.

git cassa insieme a o --patch è usato per ripristinare i percorsi modificati o cancellati a
il loro contenuto originale dall'indice o sostituire i percorsi con i contenuti di un nome
(il più delle volte un commit-ish).

L'indice può contenere voci non unite a causa di una precedente unione non riuscita. Per impostazione predefinita,
se provi a estrarre una voce di questo tipo dall'indice, l'operazione di checkout fallirà
e nulla verrà verificato. L'utilizzo di -f ignorerà queste voci non unite. Il
i contenuti da un lato specifico dell'unione possono essere estratti dall'indice usando
--nostro o --loro. Con -m, le modifiche apportate al file dell'albero di lavoro possono essere scartate in
ricreare il risultato dell'unione originale in conflitto.

VERSIONI

-q, --silenzioso
Tranquillo, sopprimere i messaggi di feedback.

--[nessun progresso
Lo stato di avanzamento viene riportato sul flusso di errore standard per impostazione predefinita quando lo è
collegato a un terminale, a meno che non sia specificato --quiet. Questo flag consente il progresso
segnalazione anche se non collegata a un terminale, indipendentemente da --quiet.

-f, --forza
Quando si cambia ramo, procedere anche se l'indice o l'albero di lavoro è diverso da
TESTA. Questo è usato per eliminare le modifiche locali.

Quando si estrae percorsi dall'indice, non fallire sulle voci non unite; Invece,
le voci non unite vengono ignorate.

--nostro, --loro
Quando estrai i percorsi dall'indice, controlla la fase #2 (orso) o #3 (il loro) per
percorsi non uniti.

Nota che durante git rebase e git pull --rebase, orso e il loro può apparire scambiato;
--ours fornisce la versione del ramo su cui si basano le modifiche, mentre --theirs
fornisce la versione del ramo che contiene il tuo lavoro che viene ribasato.

Questo perché rebase viene utilizzato in un flusso di lavoro che tratta la cronologia sul telecomando come
quello canonico condiviso, e tratta il lavoro svolto sul ramo che stai rifondando come
il lavoro di terze parti da integrare e stai assumendo temporaneamente il ruolo di
il custode della storia canonica durante il rebase. Come il custode del canonico
cronologia, è necessario visualizzare la cronologia dal telecomando come nostra (cioè "nostra condivisa
storia canonica"), mentre quello che hai fatto dalla tua parte si ramifica come loro (cioè "uno
il lavoro del collaboratore su di esso").

-B
Crea un nuovo ramo chiamato e inizia da ; vedere idiota-
ramo(1) per i dettagli.

-B
Crea il ramo e inizia da ; se esiste già,
quindi ripristinalo su . Ciò equivale a eseguire "git branch" con "-f";
vedere git-ramo(1) per i dettagli.

-t, --traccia
Quando si crea un nuovo ramo, impostare la configurazione "a monte". Vedi "--track" in idiota-
ramo(1) per i dettagli.

Se no -b è data l'opzione, il nome del nuovo ramo sarà derivato da
ramo di tracciamento remoto, guardando la parte locale della refspec configurata per il
telecomando corrispondente, quindi rimuovendo la parte iniziale fino a "*". Questo sarebbe
dicci di usare "hack" come ramo locale quando si dirama da "origin/hack" (o
"remoti/origine/hack", o anche "refs/remoti/origine/hack"). Se il nome dato non ha
barra, o l'ipotesi precedente risulta in un nome vuoto, l'ipotesi viene interrotta. Voi
può dare esplicitamente un nome con -b in tal caso.

--nessuna traccia
Non impostare la configurazione "upstream", anche se branch.autoSetupMerge
variabile di configurazione è vero.

-l
Creare il reflog del nuovo ramo; vedere git-ramo(1) per i dettagli.

--stacca
Invece di controllare un ramo per lavorarci, controlla un commit per l'ispezione e
esperimenti da scartare. Questo è il comportamento predefinito di "git checkout " quando
non è un nome di filiale. Vedere la sezione "TESTA DISTACCATA" di seguito per i dettagli.

--orfano
Crea un nuovo orfano ramo, chiamato , iniziato da e cambia
ad esso. Il primo commit effettuato su questo nuovo ramo non avrà genitori e sarà
la radice di una nuova storia totalmente slegata da tutti gli altri rami e
commette.

L'indice e l'albero di lavoro vengono regolati come se avessi precedentemente eseguito "git checkout
". Questo ti permette di iniziare una nuova cronologia che registra un insieme di percorsi
simile a eseguendo facilmente "git commit -a" per eseguire il commit di root.

Questo può essere utile quando vuoi pubblicare l'albero da un commit senza esporre
tutta la sua storia. Potresti volerlo fare per pubblicare un ramo open source di a
progetto il cui albero corrente è "pulito", ma la cui cronologia completa contiene proprietà o
bit di codice altrimenti ingombrati.

Se vuoi iniziare una cronologia disconnessa che registra un insieme di percorsi che è
totalmente diverso da quello di , allora dovresti cancellare l'indice e
l'albero di lavoro subito dopo aver creato il ramo orfano eseguendo "git rm -rf ." a partire dal
il livello più alto dell'albero di lavoro. Dopo sarai pronto per preparare il tuo nuovo
file, ripopolando l'albero di lavoro, copiandoli da altrove, estraendo a
tarball, ecc.

--ignore-skip-worktree-bit
In modalità checkout sparso, git checkout -- aggiornerebbe solo le voci corrispondenti a
e modelli sparsi in $GIT_DIR/info/sparse-checkout. Questa opzione ignora il
modelli sparsi e aggiunge di nuovo tutti i file in .

-m, --unisci
Quando si cambia ramo, se si hanno modifiche locali a uno o più file che sono
diverso tra il ramo corrente e il ramo a cui si sta passando, il
Il comando si rifiuta di cambiare ramo per preservare le modifiche nel contesto.
Tuttavia, con questa opzione, un'unione a tre vie tra il ramo corrente, il tuo lavoro
contenuto dell'albero, e il nuovo ramo è fatto, e sarai sul nuovo ramo.

Quando si verifica un conflitto di unione, le voci di indice per i percorsi in conflitto vengono lasciate
unmerged, e devi risolvere i conflitti e contrassegnare i percorsi risolti con git
add (o git rm se l'unione dovrebbe comportare la cancellazione del percorso).

Quando estrai i percorsi dall'indice, questa opzione ti consente di ricreare il conflitto
unire nei percorsi specificati.

--conflict=
Lo stesso dell'opzione --merge sopra, ma cambia il modo in cui sono i pezzi in conflitto
presentato, sovrascrivendo la variabile di configurazione merge.conflictStyle. Valori possibili
sono "merge" (default) e "diff3" (oltre a quanto mostrato dallo stile "merge",
mostra il contenuto originale).

-p, --patch
Seleziona interattivamente i pezzi nella differenza tra i (o l'indice, se
non specificato) e l'albero di lavoro. I pezzi scelti vengono quindi applicati in senso inverso al
albero funzionante (e se a è stato specificato, l'indice).

Ciò significa che puoi utilizzare git checkout -p per eliminare selettivamente le modifiche dal tuo
albero di lavoro corrente. Vedere la sezione "Modalità interattiva" di git-aggiungi(1) per imparare a
utilizzare la modalità --patch.

--ignora-altri-alberi di lavoro
git checkout si rifiuta quando il riferimento desiderato è già stato estratto da un altro albero di lavoro.
Questa opzione fa sì che controlli comunque il riferimento. In altre parole, il riferimento può essere tenuto da
più di un worktree.


Filiale alla cassa; se si riferisce a un ramo (cioè un nome che, quando è preceduto da
"refs/heads/", è un riferimento valido), quindi quel ramo viene estratto. Altrimenti, se
si riferisce a un commit valido, il tuo HEAD diventa "staccato" e non sei più su nessuno
filiale (vedi sotto per i dettagli).

Come caso speciale, la sintassi "@{-N}" per l'N-esimo ultimo ramo/commit viene ritirata
rami (invece di staccarsi). Puoi anche specificare - che è sinonimo di
"@{-1}".

Come ulteriore caso speciale, puoi usare "A...B" come scorciatoia per la base di fusione di A
e B se esiste esattamente una base di unione. Puoi tralasciare al massimo uno tra A e B, in
nel qual caso il valore predefinito è HEAD.


Nome per il nuovo ramo.


Il nome di un commit da cui iniziare il nuovo ramo; vedere git-ramo(1) per i dettagli.
L'impostazione predefinita è HEAD.


Albero da cui effettuare il checkout (quando vengono forniti i percorsi). Se non specificato, l'indice sarà
Usato.

DISTACCATO TESTA

HEAD normalmente si riferisce a un ramo denominato (es Mastercard). Nel frattempo, ogni ramo si riferisce a a
impegno specifico. Diamo un'occhiata a un repository con tre commit, uno dei quali taggato e con
ramo Mastercard controllato:

HEAD (si riferisce al ramo 'master')
|
v
a---b---c branch 'master' (si riferisce al commit 'c')
^
|
tag 'v2.0' (si riferisce al commit 'b')

Quando viene creato un commit in questo stato, il ramo viene aggiornato per fare riferimento al nuovo commit.
specificamente, git commettere crea un nuovo commit d, il cui genitore è commit c, e poi
ramo aggiornamenti Mastercard fare riferimento a un nuovo commit d. HEAD si riferisce ancora al ramo Mastercard e così
indirettamente ora si riferisce a commit d:

$ modifica; git add; git commit

HEAD (si riferisce al ramo 'master')
|
v
a---b---c---d branch 'master' (si riferisce al commit 'd')
^
|
tag 'v2.0' (si riferisce al commit 'b')

A volte è utile poter eseguire il checkout di un commit che non è sulla punta di alcun nome
branch, o anche per creare un nuovo commit a cui non fa riferimento un branch denominato. andiamo
guarda cosa succede quando effettuiamo il checkout commit b (qui mostriamo due modi in cui questo può essere fatto):

$ git checkout v2.0 # o
$ git checkout master^^

HEAD (si riferisce al commit 'b')
|
v
a---b---c---d branch 'master' (si riferisce al commit 'd')
^
|
tag 'v2.0' (si riferisce al commit 'b')

Nota che indipendentemente dal comando di checkout che usiamo, HEAD ora si riferisce direttamente a
commettere b. Questo è noto come lo stato HEAD distaccato. Significa semplicemente che HEAD si riferisce
a un commit specifico, invece di fare riferimento a un ramo denominato. vediamo cosa succede
quando creiamo un commit:

$ modifica; git add; git commit

HEAD (si riferisce al commit 'e')
|
v
e
/
a---b---c---d branch 'master' (si riferisce al commit 'd')
^
|
tag 'v2.0' (si riferisce al commit 'b')

Ora c'è un nuovo commit e, ma è referenziato solo da HEAD. Ovviamente possiamo aggiungere ancora
un altro commit in questo stato:

$ modifica; git add; git commit

HEAD (si riferisce al commit 'f')
|
v
e--f
/
a---b---c---d branch 'master' (si riferisce al commit 'd')
^
|
tag 'v2.0' (si riferisce al commit 'b')

Infatti, possiamo eseguire tutte le normali operazioni di Git. Ma vediamo cosa succede
quando poi controlliamo il master:

$ git checkout master

HEAD (si riferisce al ramo 'master')
e---f |
/v
a---b---c---d branch 'master' (si riferisce al commit 'd')
^
|
tag 'v2.0' (si riferisce al commit 'b')

È importante rendersi conto che a questo punto nulla si riferisce a commit f. Infine
commettere f (e per estensione commit e) verrà eliminato dalla routine Git garbage collection
processo, a meno che non creiamo un riferimento prima che ciò accada. Se non ci siamo ancora trasferiti
da commit f, uno di questi creerà un riferimento ad esso:

$ git verifica -b foo (1)
$ git ramo foo (2)
$ git tag pippo (3)

1. crea un nuovo ramo foo, che si riferisce a commit f, quindi aggiorna HEAD a cui fare riferimento
ramo foo. In altre parole, non saremo più nello stato HEAD staccato dopo questo comando.
2. allo stesso modo crea un nuovo ramo foo, che si riferisce a commit f, ma lascia la TESTA staccata.
3. crea un nuovo tag foo, che si riferisce a commit f, lasciando la TESTA staccata.

Se ci siamo allontanati dal commit f, quindi dobbiamo prima recuperare il nome dell'oggetto (tipicamente
usando git reflog), e quindi possiamo creare un riferimento ad esso. Ad esempio, per vedere il
ultimi due commit a cui si riferiva HEAD, possiamo usare uno di questi comandi:

$ git reflog -2 HEAD # o
$ git log -g -2 TESTA

ESEMPI

1. La seguente sequenza controlla il ramo principale, riporta il Makefile a due
revisioni indietro, elimina hello.c per errore e lo recupera dall'indice.

$ git checkout master (1)
$ git checkout master~2 Makefile (2)
$ rm -f ciao.c
$ git checkout ciao.c (3)

1. cambia ramo
2. prendi un file da un altro commit
3. ripristina hello.c dall'indice

Se si desidera controllare contro tutti i File sorgente C fuori dall'indice, puoi dire

$ git checkout -- '*.c'

Nota le virgolette intorno a *.c. Verrà estratto anche il file hello.c, anche se
non è più nell'albero di lavoro, perché il file globbing viene utilizzato per abbinare le voci
nell'indice (non nell'albero di lavoro della shell).

Se hai un ramo sfortunato che si chiama hello.c, questo passaggio sarebbe confuso
come istruzione per passare a quel ramo. Dovresti invece scrivere:

$ git checkout -- ciao.c

2. Dopo aver lavorato nel ramo sbagliato, il passaggio al ramo corretto sarebbe stato fatto
utilizzando:

$ git checkout argomento mitico

Tuttavia, il tuo ramo "sbagliato" e il ramo "mitopico" corretto potrebbero differire nei file che
hanno modificato localmente, nel qual caso il checkout di cui sopra fallirebbe in questo modo:

$ git checkout argomento mitico
errore: hai modifiche locali a 'frotz'; non cambiare ramo.

Puoi dare il flag -m al comando, che proverebbe un'unione a tre vie:

$ git checkout -m argomento mio
Frotz di fusione automatica

Dopo questa fusione a tre vie, le modifiche locali sono non è un registrato nel tuo indice
file, quindi git diff ti mostrerebbe quali modifiche hai apportato dall'inizio del nuovo
ramo.

3. Quando si verifica un conflitto di unione durante il passaggio di rami con l'opzione -m, dovresti
vedi qualcosa del genere:

$ git checkout -m argomento mio
Frotz di fusione automatica
ERRORE: Unisci conflitto in frotz
fatale: programma di unione fallito

A questo punto, git diff mostra le modifiche unite in modo pulito come nell'esempio precedente,
così come le modifiche nei file in conflitto. Modifica e risolvi il conflitto e contrassegna
si è risolto con git add come al solito:

$ modifica frotz
$ git aggiungi frotz

GIT

Parte della git(1) seguito

Usa git-checkout online utilizzando i servizi onworks.net