2011-09-04 10 views
88

Ok. Se sono su una diramazione (ad esempio working) e voglio unire le modifiche da un altro ramo (ad esempio master), eseguo il comando git-merge master mentre sul ramo working e le modifiche vengono incorporate senza rebasare la cronologia affatto. Se eseguo git-rebase master, le modifiche in master vengono ridefinite per essere inserite nella parte superiore del ramo working. Ma cosa succede se voglio unire le modifiche da master ma ribaltare le mie modifiche in working per essere in cima? Come lo faccio? Può essere fatto?Come rebase le modifiche del ramo corrente in aggiunta alle modifiche in corso di integrazione?

ho potuto eseguire git-rebase working sul mio master ramo di mettere le mie modifiche sulla parte superiore nel ramo master, ma mi piacerebbe essere in grado di farlo nel mio working ramo, e non ho idea di come. Il più vicino che posso pensare di fare è creare un nuovo ramo da master e quindi rifare le modifiche di working in cima a quello, ma poi avrei un nuovo ramo invece di alterare il ramo working.

risposta

173

Hai quello che fa rebase all'indietro. git rebase master fa quello che stai chiedendo - prende le modifiche sul ramo corrente (dalla sua divergenza dal master) e le riproduce su master, quindi imposta il capo del ramo corrente come capo di quella nuova storia. Lo non riproduce le modifiche da master in cima al ramo corrente.

+0

LOL. Ahia. Grazie per avermi corretto. Proprio quando pensavo di aver capito tutto ... –

+2

@Jonathan è bello. Questo è un po 'un argomento difficile. A proposito, 'git rebase working' sposterebbe le modifiche di' master' (dopo il punto in cui 'working' si ramificava) per essere in cima al ramo' working' - ma questa non è una cosa molto sensata da fare per ' master' :) – hobbs

41

Un altro modo di vedere le cose è quello di considerare git rebase master come:

Rebase il ramo corrente in cimamaster

Qui, 'master' è il monte ramo , e questo spiega perché, durante un rebase, ours and theirs are reversed.

+0

Ciò spiega anche perché LOCAL e REMOTE sono invertiti. Grazie. – AVIDeveloper

+0

@AVIDeveloper su LOCAL e REMOTE, puoi anche leggere http://stackoverflow.com/a/3052118/6309 – VonC

+4

@@ VonC: Grazie. Sì, dopo aver passato un pomeriggio a borbottare tra me e me "REMOTE è il mio ramo .. LOCALE non è mio", è tutto sprofondato.Onestamente, avrei preferito vedere i nomi dei rami (o abbreviazioni SHA) invece di REMOTO/LOCALE/nostro/loro/mio. I miei pensieri sono gli stessi per quanto riguarda l'orribile sinistra/destra di 'git difftool'. Un po 'fuori tema, ma per 'difftool' rimango a git-meld e mi piacciono i nomi come' working-dir ',' stash @ {0} ', così via. – AVIDeveloper

3

Ho appena fatto questo istanti fa nel seguente modo:

  1. eseguire il backup del lavoro attuale in corso git checkout -b work-in-progress
  2. fetch ultime modifiche git fetch origin/master
  3. scartare le modifiche locali git reset --hard origin/master
  4. riproduzione ultima Modifiche dal master git rebase origin/master
  5. replay i lavori in corso git rebase origin/work-in-progress
  6. sincronizza i lavori in corso con l'ultimo master git rebase origin/master
+0

Ho lavorato per me per aggiornare il ramo di lavoro corrente con l'ultimo codice. – Dragunov

+0

Questa istruzione è controintuitiva. Un nuovo ramo work-in-progress e un reset? Che ne dite di qualcosa di simile a: 1. mettere il vostro lavoro non impegnati in una scorta: 'git stash' 2. prendere ultime modifiche:' git fetch' 3. rebase dal ramo che è in vantaggio; in questo caso, master: 'git rebase origin/master' 4. tornare a lavorare su ciò che si sta facendo:' git stash pop' EDIT, non è possibile aggiungere interruzioni di riga nei commenti. lol – NathanQ

+0

Forse è controintuitivo per te, ma hai davvero letto la domanda attuale sopra? –