git-pull - Online nel cloud

PROGRAMMA:

NOME

git-pull - Recupera e integra con un altro repository o un ramo locale

SINOSSI

git tirare [opzioni] [ [ ...]]

DESCRIZIONE

Incorpora le modifiche da un repository remoto nel ramo corrente. Nella sua impostazione predefinita
mode, git pull è una scorciatoia per git fetch seguito da git merge FETCH_HEAD.

Più precisamente, git tirare corre git andare a prendere con i parametri e le chiamate dati git unire a
unire le teste del ramo recuperate nel ramo corrente. Con --rebase, viene eseguito git
rebase invece di git unire.

dovrebbe essere il nome di un repository remoto passato a git-recupera(1).
può nominare un riferimento remoto arbitrario (ad esempio, il nome di un tag) o anche a
raccolta di riferimenti con corrispondenti rami di monitoraggio remoto (ad es.
refs/heads/*:refs/remotes/origin/*), ma di solito è il nome di un ramo nel remoto
repository.

Valori predefiniti per e vengono letti da "remoto" e "unisci"
configurazione per il ramo corrente come stabilito da git-ramo(1) --traccia.

Supponiamo che esista la seguente cronologia e che il ramo corrente sia "master":

A---B---C master sull'origine
/
RE --- MI --- FA --- SOL maestro
^
origin/master nel tuo repository

Quindi "git pull" recupererà e riprodurrà le modifiche dal ramo master remoto poiché
divergeva dal master locale (cioè E) fino al suo commit corrente (C) sopra il master e
registra il risultato in un nuovo commit insieme ai nomi dei due commit genitori e un log
messaggio dell'utente che descrive le modifiche.

A---B---C origine/maestro
/ \
RE --- MI --- FA --- SOL --- H maestro

See git-merge(1) per i dettagli, incluso il modo in cui i conflitti vengono presentati e gestiti.

In Git 1.7.0 o successivo, per annullare un'unione in conflitto, usa git reset --merge. avvertimento: In
versioni precedenti di Git, in esecuzione git tirare con modifiche non impegnate è sconsigliato: mentre
possibile, ti lascia in uno stato dal quale potrebbe essere difficile uscire in caso di a
conflitto.

Se una qualsiasi delle modifiche remote si sovrappone alle modifiche locali non salvate, l'unione sarà
annullato automaticamente e l'albero di lavoro intatto. In genere è meglio prendere qualsiasi locale
cambiamenti nello stato di funzionamento prima di tirarli via o riporli via con git-stash(1).

VERSIONI

-q, --silenzioso
Questo viene passato sia a git-fetch sottostante che alla segnalazione dello squelch durante il trasferimento,
e git-merge sottostante per silenziare l'output durante la fusione.

-v, --verboso
Passa --verbose a git-fetch e git-merge.

--[no-]sottomoduli-ricorrenti[=sì|su richiesta|no]
Questa opzione controlla se devono essere recuperati anche i nuovi commit di tutti i sottomoduli popolati
(Vedi git-config(1) e gitmodules(5)). Potrebbe essere necessario per ottenere i dati necessari
per unire i commit del sottomodulo, una funzionalità appresa da Git in 1.7.3. Notare che il risultato
di un'unione non verrà estratto nel sottomodulo, "git submodule update" deve essere
chiamato in seguito per aggiornare l'albero di lavoro con il risultato dell'unione.

Opzioni relazionato a fusione
--commit, --no-commit
Eseguire l'unione e confermare il risultato. Questa opzione può essere utilizzata per sovrascrivere
--no-commettere.

Con --no-commit esegui l'unione ma fai finta che l'unione non sia riuscita e non eseguire il commit automatico,
per dare all'utente la possibilità di ispezionare e modificare ulteriormente il risultato dell'unione prima
commettere.

--edit, -e, --no-edit
Invocare un editor prima di eseguire correttamente l'unione meccanica per modificare ulteriormente il
messaggio di unione generato automaticamente, in modo che l'utente possa spiegare e giustificare l'unione. Il
l'opzione --no-edit può essere usata per accettare il messaggio generato automaticamente (questo è generalmente
scoraggiato).

Gli script più vecchi possono dipendere dal comportamento storico di non consentire all'utente di modificare
il messaggio del registro di unione. Vedranno un editor aperto quando eseguiranno git merge. Produrre
è più facile adattare tali script al comportamento aggiornato, la variabile d'ambiente
GIT_MERGE_AUTOEDIT può essere impostato su no all'inizio di essi.

--ff
Quando l'unione si risolve come un avanzamento veloce, aggiorna solo il puntatore del ramo, senza
creazione di un commit di unione. Questo è il comportamento predefinito.

--no-ff
Crea un commit di unione anche quando l'unione si risolve come un avanzamento rapido. Questo è il
comportamento predefinito durante l'unione di un tag annotato (e possibilmente firmato).

--ff-solo
Rifiuta di unire ed uscire con uno stato diverso da zero a meno che l'attuale HEAD non sia già
aggiornato o l'unione può essere risolta come un avanzamento rapido.

--log[= ], --no-log
Oltre ai nomi dei rami, compila il messaggio di registro con descrizioni di una riga da
al massimo commit effettivi che vengono uniti. Guarda anche git-fmt-merge-msg(1).

Con --no-log non elencare le descrizioni di una riga dai commit effettivi che vengono uniti.

--stat, -n, --no-stat
Mostra un diffstat alla fine dell'unione. Il differenziale è controllato anche dal
opzione di configurazione merge.stat.

Con -n o --no-stat non mostra un diffstat alla fine dell'unione.

--zucca, --no-zucca
Produci l'albero di lavoro e lo stato dell'indice come se fosse avvenuta una vera fusione (tranne che per il
unire le informazioni), ma non eseguire effettivamente un commit, spostare l'HEAD o registrare
$GIT_DIR/MERGE_HEAD (per far sì che il prossimo comando git commit crei un merge commit).
Questo ti permette di creare un singolo commit in cima al ramo corrente il cui effetto è
equivale a fondere un altro ramo (o più nel caso di un polpo).

Con --no-squash esegui l'unione e conferma il risultato. Questa opzione può essere utilizzata per
sovrascrivere --squash.

-S , --strategia=
Utilizzare la strategia di unione data; possono essere forniti più di una volta per specificarli nel
ordina che vengano provati. Se non c'è l'opzione -s, un elenco integrato di strategie è
usato invece (git unione-ricorsiva quando si unisce una singola testa, git unione-polpo
altrimenti).

-X , --strategy-option=
Passa l'opzione specifica della strategia di unione alla strategia di unione.

--verify-signatures, --no-verify-signatures
Verificare che i commit da unire abbiano firme GPG valide e affidabili e interrompere
l'unione nel caso in cui non lo facciano.

--summary, --no-summary
Sinonimi di --stat e --no-stat; questi sono deprecati e verranno rimossi nel
futuro.

-r, --rebase[=falso|vero|preserva]
Se true, ribase il ramo corrente sopra il ramo upstream dopo il recupero. Se
esiste un ramo di teletracciamento corrispondente al ramo a monte e il
il ramo a monte è stato ribasato dall'ultimo recupero, il rebase utilizza tali informazioni per
evitare di ribasare modifiche non locali.

Quando è impostato per preservare, rebase con l'opzione --preserve-merges passata a git rebase così
che i commit di unione creati localmente non verranno appiattiti.

Se false, unisce il ramo corrente nel ramo upstream.

Vedere pull.rebase, branch. .rebase e branch.autoSetupRebase in git-config(1) se
vuoi che git pull usi sempre --rebase invece di unire.

Note:
Questo è un potenziale pericoloso modalità di funzionamento. Riscrive la storia, cosa che fa
non è di buon auspicio quando hai già pubblicato quella storia. Fare non usa questa opzione
a meno che tu non abbia letto git-rebase(1) attentamente.

--no-rebase
Sostituisci in precedenza --rebase.

Opzioni relazionato a recupero
--tutti
Recupera tutti i telecomandi.

-a, --appendere
Aggiungi i nomi dei riferimenti e i nomi degli oggetti dei riferimenti recuperati ai contenuti esistenti di
.git/FETCH_HEAD. Senza questa opzione i vecchi dati in .git/FETCH_HEAD verranno sovrascritti.

--profondità=
Limita il recupero al numero specificato di commit dalla punta di ogni ramo remoto
storia. Se il recupero di a superficiale repository creato da git clone con --depth=
opzione (vedi git-clone(1)), approfondire o accorciare la cronologia al numero specificato di
commette. I tag per i commit approfonditi non vengono recuperati.

--non superficiale
Se il repository di origine è completo, converti un repository superficiale in uno completo,
rimuovendo tutte le limitazioni imposte dai repository poco profondi.

Se il repository di origine è superficiale, recupera il più possibile in modo che l'attuale
repository ha la stessa cronologia del repository di origine.

--update-superficiale
Per impostazione predefinita, quando si recupera da un repository poco profondo, git fetch rifiuta i riferimenti che
richiedono l'aggiornamento di .git/shallow. Questa opzione aggiorna .git/shallow e accetta tali riferimenti.

-f, --forza
Quando git andare a prendere è usato con : refspec, si rifiuta di aggiornare il
filiale locale a meno che il ramo remoto prende è un discendente
di . Questa opzione sovrascrive quel controllo.

-k, --mantieni
Mantieni il pacchetto scaricato.

--no-tag
Per impostazione predefinita, i tag che puntano agli oggetti che vengono scaricati dal repository remoto
vengono recuperati e archiviati localmente. Questa opzione disabilita questo tag automatico che segue. Il
il comportamento predefinito per un telecomando può essere specificato con il telecomando. .tagOpt impostazione.
See git-config(1).

-u, --update-testa-ok
Di default git andare a prendere si rifiuta di aggiornare la testa che corrisponde alla corrente
ramo. Questo flag disabilita il controllo. Questo è puramente per uso interno per git tirare
con cui comunicare git andare a prendere, e a meno che tu non stia implementando la tua Porcellana tu
non dovrebbero usarlo.

--upload-pack
Quando viene fornito, e il repository da cui prelevare è gestito da git pacchetto di raccolta,
--exec= viene passato al comando per specificare il percorso non predefinito per il
comando eseguito dall'altra parte.

--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 -q. Questa bandiera forza anche lo stato di avanzamento
se il flusso di errore standard non è diretto a un terminale.


Il repository "remoto" che è l'origine di un'operazione di recupero o pull. Questo
il parametro può essere un URL (vedere la sezione URL GIT di seguito) o il nome di un remoto
(vedi la sezione TELECOMANDI di seguito).


Specifica quali riferimenti recuperare e quali riferimenti locali aggiornare. quando no S
appaiono sulla riga di comando, i riferimenti da recuperare vengono letti da remoto. .andare a prendere
variabili invece (vedi git-recupera(1)).

Il formato di a parametro è un plus + opzionale, seguito dal riferimento sorgente
, seguito da due punti :, seguito dalla destinazione ref . Il colon può essere
omesso quando è vuoto.

etichetta significa lo stesso di refs/tags/ :refs/tag/ ; richiede il recupero
tutto fino al tag dato.

Il riferimento remoto che corrisponde viene recuperato, e se non è una stringa vuota, il
il riferimento locale che corrisponde viene eseguito l'avanzamento rapido utilizzando . Se il plus + opzionale è
utilizzato, il riferimento locale viene aggiornato anche se non risulta in un aggiornamento rapido.

Note:
Quando il ramo remoto che vuoi recuperare è noto per essere riavvolto e ribasato
regolarmente, si prevede che la sua nuova punta non discenderà dalla precedente
suggerimento (come memorizzato nel tuo ramo di monitoraggio remoto l'ultima volta che hai recuperato). Voi
vorrei usare il segno + per indicare che saranno necessari aggiornamenti non veloci
per tali rami. Non c'è modo di determinare o dichiarare che un ramo sarà
reso disponibile in un repository con questo comportamento; l'utente che tira deve semplicemente
sappi che questo è il modello di utilizzo previsto per un ramo.

Note:
C'è una differenza tra l'elenco di più direttamente su git tirare
riga di comando e avere più remoti. .recupera le voci nel tuo
configurazione per a e correndo a git tirare comando senza
esplicito parametri. sono elencati esplicitamente nella riga di comando
vengono sempre uniti al ramo corrente dopo il recupero. In altre parole, se tu
elenca più di un riferimento remoto, git tirare creerà un'unione Octopus. Dall'altra
mano, se non elenchi nessuna esplicita parametro sulla riga di comando, git
tirare prenderà tutto il s trova nel telecomando. .andare a prendere
configurazione e unire solo il primo trovato nel ramo corrente.
Questo perché fare un Octopus da riferimenti remoti viene fatto raramente, pur mantenendo
traccia di più testine remote in una volta recuperando più di una è spesso
utile.

GIT URL

In generale, gli URL contengono informazioni sul protocollo di trasporto, l'indirizzo del
server remoto e il percorso del repository. A seconda del protocollo di trasporto, alcuni
di queste informazioni possono essere assenti.

Git supporta i protocolli ssh, git, http e https (inoltre, è possibile utilizzare ftp e ftps
per il recupero e rsync può essere utilizzato per il recupero e il push, ma sono inefficienti e
deprecato; non usarli).

Il trasporto nativo (cioè git:// URL) non esegue l'autenticazione e dovrebbe essere usato con
cautela sulle reti non protette.

Con essi possono essere utilizzate le seguenti sintassi:

· ssh://[utente@]host.xz[:porta]/percorso/a/repo.git/

· git://host.xz[:porta]/percorso/a/repo.git/

· http[s]://host.xz[:porta]/percorso/to/repo.git/

· ftp[s]://host.xz[:porta]/percorso/a/repo.git/

· rsync://host.xz/percorso/a/repo.git/

Una sintassi alternativa simile a scp può essere utilizzata anche con il protocollo ssh:

· [utente@]host.xz:percorso/a/repo.git/

Questa sintassi viene riconosciuta solo se non ci sono barre prima dei primi due punti. Questo aiuta
differenziare un percorso locale che contiene i due punti. Ad esempio il percorso locale foo:bar potrebbe
essere specificato come percorso assoluto o ./foo:bar per evitare di essere interpretato erroneamente come un URL ssh.

I protocolli ssh e git supportano inoltre l'espansione ~username:

· ssh://[utente@]host.xz[:porta]/~[utente]/percorso/a/repo.git/

· git://host.xz[:porta]/~[utente]/percorso/a/repo.git/

· [utente@]host.xz:/~[utente]/percorso/a/repo.git/

Per i repository locali, supportati anche da Git in modo nativo, le seguenti sintassi potrebbero essere
usato:

· /percorso/a/repo.git/

· file:///percorso/a/repo.git/

Queste due sintassi sono per lo più equivalenti, tranne in caso di clonazione, quando la prima implica
--opzione locale. Vedere git-clone(1) per i dettagli.

Quando Git non sa come gestire un determinato protocollo di trasporto, tenta di utilizzare il
a distanza- helper remoto, se ne esiste uno. Per richiedere esplicitamente un assistente remoto,
può essere utilizzata la seguente sintassi:

· ::

dove può essere un percorso, un server e un percorso o una stringa arbitraria simile a un URL
riconosciuto dallo specifico helper remoto richiamato. Vedere gitremote helpers(1) per
dettagli.

Se c'è un gran numero di repository remoti con nomi simili e vuoi usare a
formato diverso per loro (in modo tale che gli URL che usi verranno riscritti in URL che
work), è possibile creare una sezione di configurazione del modulo:

[URL" "]
invece di =

Ad esempio, con questo:

[url "git://git.host.xz/"]
inveceOf = host.xz:/percorso/a/
inveceDi = lavoro:

un URL come "work:repo.git" o come "host.xz:/path/to/repo.git" verrà riscritto in qualsiasi
contesto che accetta un URL come "git://git.host.xz/repo.git".

Se vuoi riscrivere gli URL solo per il push, puoi creare una sezione di configurazione del
modulo:

[URL" "]
pushInsteadOf =

Ad esempio, con questo:

[url "ssh://esempio.org/"]
pushInsteadOf = git://example.org/

un URL come "git://example.org/path/to/repo.git" verrà riscritto in
"ssh://example.org/path/to/repo.git" per i push, ma i pull utilizzeranno comunque l'originale
URL.

TELECOMANDO

Il nome di uno dei seguenti può essere utilizzato al posto di un URL come discussione:

· un telecomando nel file di configurazione di Git: $GIT_DIR/config,

· un file nella directory $GIT_DIR/remotes, oppure

· un file nella directory $GIT_DIR/branches.

Tutti questi ti consentono anche di omettere refspec dalla riga di comando perché ciascuno di essi
contengono una refspec che git utilizzerà per impostazione predefinita.

Detto a distanza in configurazione filetto
Puoi scegliere di fornire il nome di un telecomando che avevi precedentemente configurato usando
git-remoto(1) git-config(1) o anche da una modifica manuale al file $GIT_DIR/config. L'URL
di questo telecomando verrà utilizzato per accedere al repository. La refspec di questo telecomando sarà
utilizzato per impostazione predefinita quando non si fornisce una refspec sulla riga di comando. L'ingresso in
il file di configurazione apparirà così:

[a distanza " "]
URL =
pushurl =
premere =
prendere =

Il viene utilizzato solo per le spinte. È facoltativo e il valore predefinito è .

Detto filetto in $GIT_DIR/telecomandi
Puoi scegliere di fornire il nome di un file in $GIT_DIR/remotes. L'URL in questo file
verrà utilizzato per accedere al repository. La refspec in questo file sarà usata come predefinita
quando non fornisci una refspec sulla riga di comando. Questo file dovrebbe avere quanto segue
formato:

URL: uno dei formati URL precedenti
Spingere:
Tiro:

Push: le linee sono usate da git spingere e Pull: le linee sono usate da git tirare ed git andare a prendere.
È possibile specificare più linee Push: e Pull: per mappature di rami aggiuntivi.

Detto filetto in $GIT_DIR/rami
Puoi scegliere di fornire il nome di un file in $GIT_DIR/branches. L'URL in questo file
verrà utilizzato per accedere al repository. Questo file dovrebbe avere il seguente formato:

#

è obbligatorio; # è facoltativo.

A seconda dell'operazione, git utilizzerà una delle seguenti specifiche di riferimento, in caso contrario
fornire uno sulla riga di comando. è il nome di questo file in $GIT_DIR/branches
e l'impostazione predefinita è master.

git fetch utilizza:

arbitri/teste/ :refs/teste/

git push utilizza:

HEAD:refs/heads/

MERGE STRATEGIE

Il meccanismo di unione (git merge e git pull) consente il backend unire strategie
da scegliere con l'opzione -s. Alcune strategie possono anche prendere le proprie opzioni, che possono essere
passato dando -X argomenti per git merge e/o git pull.

risolvere
Questo puòrisolvere solo due teste (cioè il ramo corrente e un altro ramo che hai tirato
from) utilizzando un algoritmo di unione a 3 vie. Cerca di rilevare con attenzione l'unione incrociata
ambiguità ed è considerato generalmente sicuro e veloce.

ricorsiva
Questo può risolvere solo due teste utilizzando un algoritmo di unione a 3 vie. Quando c'è più di
un antenato comune che può essere utilizzato per l'unione a 3 vie, crea un albero unito del
antenati comuni e lo usa come albero di riferimento per l'unione a 3 vie. Questo ha
stato segnalato per provocare meno conflitti di unione senza causare fusioni errate dai test
eseguito su commit effettivi di unione presi dalla cronologia di sviluppo del kernel Linux 2.6.
Inoltre, questo può rilevare e gestire le unioni che coinvolgono rinomina. Questa è l'impostazione predefinita
strategia di unione quando si estrae o si unisce un ramo.

I ricorsiva la strategia può assumere le seguenti opzioni:

orso
Questa opzione costringe i pezzi in conflitto a essere risolti automaticamente in modo pulito favorendo nostro
versione. I cambiamenti dall'altro albero che non sono in conflitto con la nostra parte sono
riflessa nel risultato dell'unione. Per un file binario, viene preso l'intero contenuto
dal nostro lato.

Questo non deve essere confuso con il orso strategia di fusione, che non sembra nemmeno
a ciò che l'altro albero contiene. Scarta tutto ciò che ha fatto l'altro albero,
dichiarando nostro la storia contiene tutto ciò che è accaduto in essa.

il loro
Questo è l'opposto di orso.

pazienza
Con questa opzione, unione-ricorsiva spende un po' di tempo in più per evitare fusioni errate
che a volte si verificano a causa di linee di corrispondenza non importanti (ad esempio, parentesi graffe da distinte
funzioni). Usalo quando i rami da unire sono divergenti selvaggiamente. Guarda anche
git-diff(1) --pazienza.

diff-algorithm=[pazienza|minimo|istogramma|myers]
Tells unione-ricorsiva utilizzare un diverso algoritmo diff, che può aiutare a evitare
errori di fusione che si verificano a causa di linee di corrispondenza non importanti (come le parentesi graffe da
funzioni distinte). Guarda anche git-diff(1) --diff-algoritmo.

ignora-spazio-cambiamento, ignora-tutto-spazio, ignora-spazio-at-eol
Tratta le righe con il tipo di spazio vuoto indicato come invariato per il
a causa di una fusione a tre vie. Modifiche degli spazi bianchi mescolate con altre modifiche a una riga
non vengono ignorati. Guarda anche git-diff(1) -b, -w e --ignore-space-at-eol.

· Se loro la versione introduce solo modifiche di spazi bianchi a una riga, nostro versione è
Usato;

· Se nostro la versione introduce modifiche agli spazi bianchi ma loro la versione include a
cambiamento sostanziale, loro viene utilizzata la versione;

· In caso contrario, l'unione procede nel modo consueto.

rinormalizzare
Questo esegue un check-out e un check-in virtuali di tutte e tre le fasi di un file quando
risoluzione di un'unione a tre vie. Questa opzione è pensata per essere utilizzata quando si uniscono rami
con diversi filtri puliti o regole di normalizzazione di fine linea. Vedi "Unire
rami con diversi attributi di check-in/check-out" in gitattributi(5) per
dettagli.

non-rinormalizzare
Disabilita l'opzione di rinormalizzazione. Questo sovrascrive il merge.renormalize
configurazione variabile.

rinomina-soglia=
Controlla la soglia di somiglianza utilizzata per il rilevamento della ridenominazione. Guarda anche git-diff(1)
-Sig.

sottoalbero[= ]
Questa opzione è una forma più avanzata di sottoalbero strategia, dove la strategia fa
un'ipotesi su come due alberi devono essere spostati in modo che corrispondano l'uno all'altro durante la fusione.
Invece, il percorso specificato è preceduto (o spogliato dall'inizio) per rendere
la forma di due alberi da abbinare.

polipo
Questo risolve i casi con più di due teste, ma si rifiuta di fare un'unione complessa che
necessita di risoluzione manuale. È pensato principalmente per essere utilizzato per raggruppare rami di argomenti
teste insieme. Questa è la strategia di unione predefinita quando si estrae o si unisce più di
un ramo.

orso
Questo risolve qualsiasi numero di teste, ma l'albero risultante dell'unione è sempre quello
della testata del ramo corrente, ignorando di fatto tutte le modifiche da tutti gli altri rami.
È pensato per essere utilizzato per sostituire la vecchia storia di sviluppo dei rami laterali. Nota
che questo è diverso dall'opzione -Xours al ricorsiva strategia di fusione.

sottoalbero
Questa è una strategia ricorsiva modificata. Quando si uniscono gli alberi A e B, se B corrisponde a
un sottoalbero di A, B viene prima aggiustato in modo che corrisponda alla struttura ad albero di A, invece di
leggendo gli alberi allo stesso livello. Questa regolazione viene effettuata anche sul comune
albero antenato.

Con le strategie che utilizzano l'unione a 3 vie (inclusa l'impostazione predefinita, ricorsiva), se un cambiamento
viene effettuato su entrambi i rami, ma in seguito viene ripristinato su uno dei rami, tale cambiamento sarà
presente nel risultato unito; alcune persone trovano questo comportamento confuso. Si verifica perché
solo le teste e la base di fusione vengono considerate quando si esegue una fusione, non il
impegni individuali. L'algoritmo di unione quindi considera la modifica annullata come no
cambia del tutto e sostituisce invece la versione modificata.

PREDEFINITO COMPORTAMENTO

Spesso le persone usano git pull senza fornire alcun parametro. Tradizionalmente, questo è stato
equivalente a dire git pull origin. Tuttavia, quando il ramo di configurazione. .remoto è
presente mentre si è in filiale , viene utilizzato quel valore al posto di origin.

Per determinare quale URL utilizzare per il recupero, il valore della configurazione
a distanza. .url viene consultato e se non esiste tale variabile, il valore su URL:
riga ` in `$GIT_DIR/remoti/ viene utilizzato il file.

Per determinare quali rami remoti recuperare (e facoltativamente archiviare nel
rami di tracciamento remoto) quando il comando viene eseguito senza alcun parametro refspec sul
riga di comando, valori della variabile di configurazione remote. .fetch vengono consultati,
e se non ce ne sono, $GIT_DIR/remotes/ viene consultato il file e il suo `Pull: `
vengono utilizzate le linee. Oltre ai formati refspec descritti nella sezione OPZIONI, tu
può avere una refspec globbing simile a questa:

refs/heads/*:refs/remoti/origine/*

Una refspec globbing deve avere un RHS non vuoto (cioè deve memorizzare ciò che è stato recuperato in
rami di tracciamento remoto) e i suoi LHS e RHS devono terminare con /*. Quanto sopra specifica che
tutte le filiali remote vengono tracciate utilizzando le filiali di monitoraggio remoto in refs/remotes/origin/
gerarchia sotto lo stesso nome.

La regola per determinare quale ramo remoto unire dopo il recupero è un po' complicata, in
per non violare la retrocompatibilità.

Se sono stati forniti refspec espliciti sulla riga di comando di git pull, vengono tutti uniti.

Quando non è stato fornito alcun refspec sulla riga di comando, git pull utilizza il refspec dal
configurazione o $GIT_DIR/remoti/ . In tali casi, si applicano le seguenti regole:

1. Se ramo. .merge configurazione per il ramo corrente esiste, cioè il
nome del ramo nel sito remoto che viene unito.

2. Se refspec è globbing, non viene unito nulla.

3. Altrimenti viene unito il ramo remoto della prima refspec.

ESEMPI

· Aggiorna i rami di monitoraggio remoto per il repository da cui hai clonato, quindi uniscine uno
di loro nel tuo ramo attuale:

$ git pull, git pull origine

Normalmente il ramo unito è l'HEAD del repository remoto, ma la scelta è
determinato dalla filiale. .remoto e filiale. .Unisci opzioni; vedere idiota-
config(1) per i dettagli.

· Unisci al ramo corrente il ramo remoto successivo:

$ git pull origin successivo

Questo lascia temporaneamente una copia di next in FETCH_HEAD, ma non ne aggiorna nessuno
filiali a distanza. Utilizzando filiali di monitoraggio remoto, lo stesso può essere fatto da
invocando il recupero e l'unione:

$ git recupera l'origine
$ git merge origine/successivo

Se hai provato un pull che ha portato a conflitti complessi e vorresti ricominciare da capo, tu
può recuperare con git azzerare.

Usa git-pull online utilizzando i servizi onworks.net