2016-06-08 6 views
9

Scenario: ho biforcato un progetto github e ho iniziato a lavorarci sopra (dopo aver aggiunto il progetto originale come remoto chiamato 'upstream'). Durante il lavoro sulla mia forcella, sono state apportate diverse versioni al progetto upstream: v1.3-stable, v1.4-stable, v1.5-experimental, ecc. Ora ho bisogno di unire i commit upstream al mio ramo master , ma SOLO fino a una versione specifica, ad esempio, rilascia v1.4-stable. Qual è il miglior flusso di lavoro per questo scenario?Git merge commit da una specifica release upstream

+0

Potrebbe fornire un link per il repo GitHub? –

risposta

3

Supponendo v1.4-stabile è un tag sul telecomando, è possibile applicare tali modifiche al repository locale, chiamando questo dal ramo che contiene il vostro lavoro:

git fetch 
git rebase --onto $(git rev-list -n1 v1.4-stable) 

Rev-list trova l'ID dell'ultimo commit di v1.4-stable, dopo il quale i commit vengono ripetuti e il tuo lavoro è posizionato in ordine. Ci saranno conflitti se il telecomando è cambiato in modo significativo da quando hai biforcuto.

Se v1.4-stabile è un ramo del telecomando si invece vuole fare

git pull --rebase origin v1.4-stable 
+0

Perché non unire semplicemente il ramo o il tag? Perché il rebase? Ciò semplifica il tracciamento delle unioni. – jszakmeister

+0

Potrei rispondere alla mia domanda qui, ma penso che sia perché credi che l'OP stia cercando di integrare il loro lavoro a monte ... nel qual caso, un rebase ha un senso. – jszakmeister

1

Innanzitutto assicurati di lavorare in una filiale dedicata per v1.5-experimental.

In secondo luogo, ripristinare il branch master a monte/V1.4 (assicurarsi che non si dispone di alcun lavoro in corso: un hard reset sarebbe spazzarli via)

git fetch upstream 
git checkout master 
git reset --hard upstream/v1.4 
git push -f 

Infine, Rebase tua v1. ramo 5-exprimental sulla parte superiore del master (che è in cima alla v1.4)

Pugno, activate rerere (nel caso in cui quello che dovete fare rebase più tardi: in grado di registrare come risolvere i conflitti simili in passato)

git config --global rerere.enabled true 

Poi REBASE (ripetere la vostra commettere dal ramo in cima v1.4):

git checkout v1.5-experimental 
git rebase master 
git push -f 

I conflitti si dovrà risolvere ci dovrebbe essere solo i conflitti di interesse (modifiche simultanee fatte sia in upstream e nella vostra ramo sperimentale).

+0

Stai dicendo a qualcuno di eseguire 'git reset --hard' sul loro repository. Almeno avvertire sulle possibili conseguenze ... –

+0

@HaraldNordgren grazie. Ho modificato la mia risposta di conseguenza. – VonC

+1

Cosa ti fa pensare che non avrebbero lavori in corso? Il punto centrale di questa domanda sembra essere la ridefinizione per consolidare il lavoro personale con le modifiche sul telecomando. Un reset git sembra decisamente distruttivo. –

2

Questo presuppone che v1.4-stable è un un tag per un commit che indica l'uscita, sul ramo master. Checkout padrone e tirare le ultime modifiche:

git checkout master 
git pull --rebase 

Avanti, aggiustano il vostro ramo di sviluppo in cima a questa commettere. Assicurati che il tuo albero di lavoro è pulito e la testa è rivolta al dev-filiale:

git rebase v.14-stable 

Questo comando cambierà la base del vostro ramo per includere il tag v.1.4-stable commit, e tutte le altre versioni che lo precedono.

Prima rebase:

o---o---v.1.2---v.1.3---v.1.4---v.1.5-exp master 
    \ 
     o---o---o dev 

Dopo:

o---o---v.1.2---v.1.3---v.1.4---v.1.5-exp master 
          \ 
          o---o---o dev 
-1
git pull --rebase origin v1.4-stable