git - cherry-pick - HOWTO/WHYTO

Question

Problema: si desidera testare una funzionalità sviluppata da qualcuno, ma solo in un ramo remoto che è tristemente obsoleto esiste solo lo .

Source

1. Come cherry-pick risolvere il problema?
2. Perché non userò git am o git apply?

Answer 1

Problema: Si desidera provare una caratteristica qualcuno ha sviluppato, ma solo esiste in un ramo remoto che è tristemente fuori moda.

Se si sono uniti o rebasati, si otterrebbero un po 'di vecchie modifiche, possibilmente in conflitto.

Con cherry picking, si prende un set di modifiche e si riproduce come un nuovo commit su un altro ramo.

Questo è utile se si desidera solo un commit su un altro ramo, senza la sua cronologia.

È utile utilizzare l'opzione -x, in modo che il messaggio di commit contenga una nota da cui è stata selezionata la ciliegia.

Perché non userò git am o git apply?

poiché git apply serve per applicare patch (file) e git am per applicare serie di patch. git cherry-pick applica commit - cioè, commette dal tuo repository, contro commit da altri repository.

Answer 2

Da git help cherry-pick:

git-cherry-pick - Applicare le modifiche introdotte da alcuni esistenti commette

[...]

Dato uno o commette più esistente, applicare la cambia ciascuno di essi introduce, registrando un nuovo commit per ciascuno. Ciò richiede che l'albero di lavoro sia pulito (nessuna modifica dal commit HEAD).

Così, quando si cherry-pick un impegnano, git prende che i cambiamenti di commit (la sua diff) e cerca di applicarlo sulla vostra directory di lavoro corrente, creando un nuovo commit che è equivalente a quello che si sta cherry-pick ing.

È un modo per ripetere le modifiche di un altro commit su una diversa cronologia.

Oltre a prendere le modifiche, cherry-pick conserva anche le informazioni di commit originale come autore e quello.

Infine, cherry-pick può ricevere un gruppo di commit da applicare, nel qual caso si comporterebbe come cherry-pick singolarmente, in ordine cronologico (prima i più vecchi).

Answer 3

Problema:
Si desidera provare una caratteristica che qualcuno si è sviluppata, ma esiste solo in un ramo remoto che è tristemente fuori moda.

si risolve il problema perché:

• non si vuole fondere il vecchio ramo tra cui commit, che non sono più rilevanti nel vostro stato attuale di sviluppo
• non si vuole rebase il tuo ramo su un vecchio ramo solo per ottenere quel commit.
• non dovrete per unire indietro il vostro ramo a quel vecchio ramo

L'ultimo punto è importante perché il primo inconveniente di cherry-picking è che esso introduce duplicate commits. Ma nel tuo caso, non importa.

L'altro svantaggio è che il commit si sono cherry-picking potrebbe avere functional dependencies basa su commit precedenti (di quel vecchio ramo).
In altre parole, il suo codice funziona solo a causa di altri codici di altri commit precedenti (che non vengono selezionati con la ciliegia).
Che può essere più difficile da rilevare.