2010-07-14 17 views
9

Quando ho una correzione per una modifica che è stata commessa alcuni prima, finisco sempre per eseguire rebase due volte di seguito. È possibile fare tutto questo in un unico passaggio? Diciamo che ho 4 nuovi commit.Posso rebase e squash commit allo stesso tempo?

* (master) D 
* C 
* B 
* A 
* Base 

ho trovato un bug in B così creo un ramo e risolvere il problema.

* (master) D 
* C 
| * (fix) Fix. 
|/ 
* B 
* A 
* Base 

Poi ho eseguito git rebase --onto fix B D spostare C e D sul B.

* (master) D' 
* C' 
* (fix) Fix. 
* B 
* A 
* Base 

Infine corro git rebase --i fix^^ a vedere gli ultimi impegna e mi schiacciare B e fissare in un unico commit.

* (master) D' 
* C' 
* B' 
* A 
* Base 

Esiste un modo più rapido per eseguire lo stesso flusso di lavoro? Immagino che la fusione sarebbe più facile, ma la fusione è fuori per me perché sto usando git svn che richiede una storia lineare.

+2

forse le opzioni 'fixup' e' autosquash' potrebbero aiutare qui? http://stackoverflow.com/questions/2302736/trimming-git-checkins-squashing-git-history/2302947#2302947 – VonC

+0

@VonC Grazie, almeno renderà questi passaggi un po 'più veloci. –

+0

eccellente (per cominciare). Puoi pubblicare una risposta che illustri come i passaggi siano più veloci con quelle opzioni. – VonC

risposta

5

Quando viene visualizzato l'editor per l'elenco di commit in un rebase interattivo, è possibile aggiungere, rimuovere o riordinare i commit a proprio piacimento. Fondamentalmente è un modo per influenzare il cherry-picking-in-a-loop che sta per aver luogo (questo è il significato di rebase in).

+0

La parte ADD è ciò che mi mancava. Grazie. –

3

Sei a conoscenza dell'opzione --squash su git merge?

--squash

produrre l'albero di lavoro e lo stato indice come se una vera e propria fusione è accaduto (ad eccezione delle informazioni merge), ma in realtà non fanno un commit o spostare il HEAD, nè registrare $GIT_DIR/MERGE_HEAD per causare il next comando git commit per creare un commit merge. Ciò consente di creare un singolo commit sopra il ramo corrente il cui effetto è lo stesso di un altro ramo (o più nel caso di un polipo).

+0

+1 perché non sapevo --squash. Tuttavia questo richiede lo stesso numero di passaggi. Dopo aver creato la correzione, invece di due rebase, avrei dovuto fare git merge --quash, quindi git commit alla testa, e quindi git rebase -i per riordinare e schiacciare la correzione nel commit con il bug. –

Problemi correlati