Git pull senza checkout?

133

Sono abituato a eseguire git pull e altri comandi dall'interno di un ramo su cui sto lavorando. Ma ho impostato un server di sviluppo su cui lavorano diverse persone, quindi non voglio dover cambiare ramo quando lo faccio. Se voglio aggiornare un ramo esistente sul server dev dal repository GitHub che tutti usiamo, quale sarebbe il modo giusto per farlo? Se eseguo il comando "git pull github branchname", verrà semplicemente trascinato il ramo nel ramo corrente?

Tutti gli esempi di git che riesco a trovare sembrano indicare che esegui prima "checkout branchname", quindi esegui il pull. Sto cercando di evitarlo. Come ho detto, questo è un ramo esistente e voglio solo aggiornarlo all'ultima versione.

git

— Diana Saunders
fonte

6

git fetchdovrebbe fare quello che vuoi.

— Brad

11

git fetchaggiorna la copia locale del ramo remoto, ma non qualsiasi ramo locale, anche se uno è impostato per tenere traccia di quel ramo remoto specifico. Può essere o non essere ciò che si vuole. (Modifica: di default, comunque. È possibile chiamarlo con argomenti per farlo comportare in modo diverso, ma in tal caso, gli argomenti dovrebbero davvero essere evidenziati.)

2

Non capisco bene ... stanno tutti usando lo stesso repository locale sul server di sviluppo? È per questo che non vuoi cambiare ramo? Perché non fare in modo che ognuno crei il proprio clone privato su cui lavorare? Vedi anche git: aggiornare un ramo locale senza verificarlo? .

Possibile duplicato di Merge, update e pull di rami Git senza utilizzare checkout

— Michael Mrozek

221

Stavo cercando la stessa cosa e finalmente ho trovato la risposta che ha funzionato per me in un altro post di stackoverflow: Unisci, aggiorna e estrai i rami Git senza usare i checkout

Fondamentalmente:

git fetch <remote> <srcBranch>:<destBranch>

— Koral
fonte

C'è un modo per utilizzare il ramo a monte invece di specificare il ramo di origine?

— cambunctious

Purtroppo, ma l' pullha parametri che il fetchnon: -s <strategy>, -Xsubtree=...che era un vitale per me, quindi questo non è un sostituto equivalente. Ho avuto il problema descritto qui: congruityservice.com/blog/… ma nel mio caso non volevo affatto un checkout.

— Andry

2

Considerando che la domanda riguarda il pull, sembra che la risposta dovrebbe invece essere git pull <remote> <srcBranch>:<destBranch>.

— J marmotta

Se i commit sono già nel tuo repository locale:git fetch . origin/master:master

— Evan

74

Ho avuto lo stesso problema con la necessità di eseguire il commit o l'archiviazione delle modifiche alle funzionalità correnti , eseguire il checkout del ramo principale , eseguire il pullcomando per ottenere tutto dallo masterspazio di lavoro remoto a quello locale , quindi passare di nuovo a un ramo delle funzionalità ed eseguire un rebaseper renderlo aggiornato con maestro.

Per fare tutto questo, mantieni l'area di lavoro sul ramo delle funzionalità ed evita tutti i cambi, lo faccio:

git fetch origin master:master

git rebase master

E fa bene il trucco.

— Marcin TP Łuczyński
fonte

19

Questo è un buon consiglio ma seppellisce la lede: per le risposte seguenti, se sei attivo featuree TUTTO quello che vuoi fare è aggiornare il tuo locale masterper essere in linea con l'origine, SENZA toccare feature, fallo git fetch origin master:mastere basta ... ed è come se lo facessi riporre-checkoutMaster-pull-checkoutFeature-stashPop!

— btown

7

Per unire il master di origine nel tuo ramo locale, non è necessario estrarre il master locale. Puoi usare git merge origin/master

— Dan

-1

Se desideri che i suggerimenti per le filiali locali vengano reindirizzati dopo git fetch, hai bisogno di alcuni passaggi aggiuntivi.

Più concretamente, si supponga che il repo GitHub ha filiali D, B, C, e master(il motivo di questa strana branch-name-set sarà chiaro in un momento). Sei sull'host devhoste sei in un repository dove si origintrova il repository GitHub. Tu fai git fetch, che porta più di tutti gli oggetti e gli aggiornamenti origin/D, origin/B, origin/C, e origin/master. Fin qui tutto bene. Ma ora dici che vuoi che accada qualcosa, su devhost, a locali rami D, B, C, e / o master?

Ho queste ovvie (per me comunque) domande:

Perché vuoi aggiornare i suggerimenti di tutte le filiali?
Cosa succede se qualche ramo (ad esempio B) ha commit che mancano nel repository remoto (github)? Dovrebbero essere uniti, ribasati o ...?
Cosa succede se sei su un ramo (ad esempio C) e la directory di lavoro e / o l'indice vengono modificati ma non sottoposti a commit?
Cosa succede se il repository remoto ha nuovi rami aggiunti ( A) e / o rami cancellati ( D)?

Se la risposta a (1) è "perché devhostnon è effettivamente per lo sviluppo, ma piuttostoèun mirror locale che mantiene semplicemente una copia disponibile localmente del repository GitHub in modo che tutti i nostri sviluppatori effettivi possano leggere da esso rapidamente invece di leggere lentamente da github ", quindi vuoi un" mirror "piuttosto che un repository" normale ". Non dovrebbe avere una directory di lavoro e forse non dovrebbe nemmeno accettare push, nel qual caso le domande rimanenti scompaiono.

Se c'è qualche altra risposta, (2-4) diventa problematico.

In ogni caso, ecco un modo per affrontare l'aggiornamento dei riferimenti locali basati su riferimenti remoti (dopo l'esecuzione, git fetch -pad esempio):

for ref in $(git for-each-ref refs/remotes/origin/ --format '%(refname)'); do
    local=${ref#refs/remotes/origin/}
    ... code here ...
done

Quello che va nella ... code here ...sezione dipende dalle risposte alle domande (2-4).

— Torek
fonte

-5

Uso

git fetch

anziché. Aggiorna i riferimenti remoti e gli oggetti nel repository, ma lascia da soli i rami locali, HEAD e l'albero di lavoro.

— SZG
fonte

17

Ma questo non aggiorna i rami locali del suo server di sviluppo ... aggiorna solo i rami "origin" su quella cartella git, che corrispondono al repository GitHub del richiedente.

— ANeves

1

Oppure, se vuoi la mia versione del problema: voglio unire il mio ramo di lavoro con "master" e non con "origin / master di ssh: // bla bla bla". L'esecuzione del recupero aggiornerà origin / master, ma non master.

— ANeves

-6

EDIT: Usa 'git pull' Recupererà tutti i rami dal repository e aggiornerà anche all'ultimo se il ramo esce sul sistema locale solo per il ramo corrente. Nota: git pull è equivalente a fetch + merge che recupera tutti i rami ma unisce solo il ramo corrente.

— Anuj Aneja
fonte

6

Meglio dire: pullfa un fetch (che, sì, recupera tutto dal telecomando) ma poi unisce solo il ramo corrente .

— torek

Nessuna offesa intesa con il mio voto negativo, so che quello che stai dicendo è corretto e fattuale, e l'OP ha effettivamente chiesto conferma su cosa fa pull (e gli hai dato quella spiegazione), ma non affronta il punto cruciale di ciò che stava cercando: C'è un modo per aggiornare uno dei tuoi rami locali agli ultimi commit nel suo ramo remoto associato senza dover prima effettuare il checkout del ramo.

— Gurce