git pull dal master nel ramo di sviluppo

496

Ho un ramo chiamato dmgr2 (sviluppo) e voglio estrarre dal ramo principale (sito live) e incorporare tutte le modifiche nel mio ramo di sviluppo. c'è un modo migliore per farlo? ecco cosa avevo programmato di fare dopo aver apportato modifiche:

git checkout dmgr2
git pull origin master

questo dovrebbe attirare i cambiamenti dal vivo nel mio ramo di sviluppo, o ho sbagliato?

git branch pull

— Matthew Colley
fonte

1

prima fai il commit di tutte le tue modifiche nel ramo dmgr2. e quindi punta al master 1.git checkout master e quindi ottieni l'ultima modifica 2.git pull 3.git merge dmgr2 4.git push -u origin master E poi torna al tuo dmgr2 5.git checkout dmgr2

— mat_vee

ho già eseguito tutte le modifiche al ramo dmgr2, mi spiace aver dimenticato di aggiungerlo

— Matthew Colley,

1

se eseguo il passaggio 4, non spingerà i miei cambiamenti di sviluppo in master? non voglio farlo

— Matthew Colley,

Quindi, quello che stai dicendo è che vuoi apportare le modifiche dal tuo ramo principale al tuo ramo di sviluppo?

— JcKelley,

9

Passa al devramo con a git checkout dev. Poi git pull --rebase origin master. Se sei fortunato, non ci saranno conflitti e dev avrà le ultime modifiche dal master.

— JWW

725

I passaggi che hai elencato funzioneranno, ma c'è un modo più lungo che ti dà più opzioni:

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

Il fetchcomando può essere eseguito in qualsiasi momento prima di merge, ad esempio, è possibile scambiare l'ordine del recupero e del pagamento, perché fetchpassa semplicemente al nome remoto ( origin) e gli dice: "dammi tutto quello che hai che non ho ", vale a dire, tutti si impegnano su tutti i rami. Vengono copiati nel repository, ma denominati origin/branchper qualsiasi ramo denominato branchsul telecomando.

A questo punto puoi utilizzare qualsiasi visualizzatore ( git log, gitkecc.) Per vedere "ciò che hanno" che non possiedi e viceversa. A volte questo è utile solo per Warm Fuzzy Feelings ("ah, sì, è proprio quello che voglio") e a volte è utile per cambiare completamente le strategie ("whoa, non voglio ancora QUESTA roba").

Infine, il mergecomando prende il commit dato, che puoi nominare come origin/master, e fa tutto il necessario per portare quel commit e i suoi antenati, a qualunque ramo tu sia quando esegui il file merge. Puoi inserire --no-ffo --ff-onlyimpedire un avanzamento rapido o unire solo se il risultato è un avanzamento rapido, se lo desideri.

Quando si utilizza la sequenza:

git checkout dmgr2
git pull origin master

il pullcomando ordina a git di correre git fetch, e quindi l'equivalente morale di git merge origin/master. Quindi questo è quasi lo stesso che fare i due passi a mano, ma ci sono alcune sottili differenze che probabilmente non ti riguardano troppo. (In particolare la fetchcorsa passo pullporta oltre solo origin/master , e non aggiorna l'arbitro nella repo: ¹ ogni nuovo commit venti fino cui-to solo dalla speciale FETCH_HEAD. Di riferimento)

Se usi il più esplicito git fetch origin(quindi opzionalmente guardati intorno) e poi la git merge origin/mastersequenza, puoi anche masteraggiornare il tuo locale con il telecomando, con una sola fetchcorsa sulla rete:

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

per esempio.

¹ Questa seconda parte è stata cambiata - dico "risolto" - in git 1.8.4, che ora aggiorna opportunisticamente i riferimenti "diramazione remota". (È stato, come dicono le note di rilascio, una decisione di progettazione deliberata per saltare l'aggiornamento, ma si scopre che più persone preferiscono che git lo aggiorni. Se si desidera che il vecchio ramo remoto SHA-1, per impostazione predefinita venga salvato in e quindi recuperabile dal reflog. Ciò consente anche una nuova funzionalità git 1.9 / 2.0 per la ricerca di rebase a monte.)

— Torek
fonte

28

Sto solo chiedendo un amico, come faresti per annullare il primo blocco di codice che hai qui (checkout / fetch / merge)?

— Rich Bradshaw,

10

@RichBradshaw: di git checkoutsolito non è distruttivo e di solito non c'è motivo di annullare un git fetch, quindi sembra che tu stia chiedendo come annullare un commit di merge. La risposta è la stessa di altri commit: o git resetoppure git revert. Per le modifiche non pubblicategit reset è di solito il metodo migliore; per i cambiamenti già apportati da altri, git revertpotrebbe essere migliore, ma vedi i consigli di Linus Torvald sul ripristino di una fusione: kernel.org/pub/software/scm/git/docs/howto/…

— torek,

2

@WeDoTDD: non capisco la domanda. Ci sono una serie di comandi per la visualizzazione il commit grafico ( gitk, git log --graphcon o senza --oneline, e così via) ed è possibile git showo git show -mun merge commit, o l'uso git diff. In tutti questi casi, stai specificando il programma mentre inserisci il comando dalla riga di comando.

— Torek,

1

@torek: hai provato a: git checkout branch e poi git pull origin master, ma ha tirato tutte le modifiche master come un'unica modifica che dovrebbe essere impegnata di nuovo localmente, invece di rimuoverle con la cronologia e i messaggi di commit, quindi dopo l'aggiornamento locale master e passando al ramo, "git rebase master" fa il lavoro con tutti i conflitti da risolvere, quindi aggiungo a "git pull --rebase" e gestisco nuovamente tutti i conflitti, quindi git spinge il ramo di origine per allinearli tutti. Immagino che dovrebbe esserci un modo migliore per farlo - ho ragione?

— user10556443,

1

@torek: sono d'accordo che il risultato che ho ottenuto è un processo noioso che mi costringe a gestire il rebase ripetuto e l'unione e ... ogni volta che voglio ottenere un aggiornamento dal master ... Ma, il modo proposto, che ammetto, è molto più semplice, ha ottenuto tutte le modifiche in un'unica modifica senza commit nella filiale locale senza mantenere l'ordine / cronologia del commit principale. Sarò felice di apprendere un suggerimento migliore su come usare "fetch" e tenere traccia del master senza la necessità di usare "pull" ecc.

— user10556443

14

Situazione : lavoro nella mia filiale locale, ma adoro tenere aggiornati gli aggiornamenti nella filiale di sviluppo denominata dev.

Soluzione : di solito preferisco fare:

git fetch
git rebase origin/dev

— greenridinghood
fonte

15

Con la solita dichiarazione di non responsabilità che rebase dovrebbe essere fatto solo se il ramo locale è solo locale, cioè non è stato spinto da nessuna parte mentre riscrive la storia.

— Locus,

8

Questo ha funzionato per me. Per ottenere l'ultimo codice dal master al mio ramo

git rebase origin/master

— Pratik Gaurav
fonte

Non dimenticare di git fetch originprima.

— lenooh,

3

Scenario :

Ho l'aggiornamento principale e l'aggiornamento del mio ramo, voglio che il mio ramo tenga traccia del master con il rebasing, per tenere traccia di tutta la cronologia correttamente, chiamiamo il mio ramo Mybranch

Soluzione :

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch

è necessario risolvere tutti i conflitti con git mergetool &, git rebase --continue, git rebase --skip, git add -u, a seconda della situazione e dei suggerimenti git, fino a quando tutto è risolto

(correzione all'ultima fase, per gentile concessione di Tzachi Cohen, usando "-f" forza git a "aggiornare la cronologia" sul server)

ora il ramo dovrebbe essere allineato con master e ridisegnato, anche con aggiornamento remoto, quindi su git log non ci sono "dietro" o "avanti", è sufficiente rimuovere tutti i file di conflitto * .orig locali per mantenere la cartella "pulita"

— user10556443
fonte