Perché la selezione con selezione rapida modifica più di un commit?

Ho due rami qui, ad esempio branch1 e branch2. Ci sono molte nuove funzionalità aggiunte in branch1 e branch2 è stabile. Oggi voglio unire solo 1 funzione da branch1 a branch2. Quindi, eseguo semplicemente git cherry-pick <commit-for-feature1-in-branch1. Suppongo che ci dovrebbe essere solo la modifica in <commit-for-featur1-in-branch1 sarà unita in branch2. Ma ho scoperto che ci sono altre modifiche per le altre funzionalità.Perché la selezione con selezione rapida modifica più di un commit?

Ho pensato che otterrà il diff solo per il commit specificato, giusto?

FYI, il commit in branch1 è stato unito da altro ramo di sviluppo, questo potrebbe causare questo problema?

Qualcosa di sbagliato che ho fatto?

Grazie.

fonte

2011-10-18 Rocky

Sei sicuro che specificato impegnarsi non includere più cambiamenti di quanto pensassi? – VonC

Sì, ho provato a vedere il diff di quel commit: git diff revision^revision. questo è ciò di cui ho bisogno. – Rocky

Ciò che git cherry-pick fa è il commit che si specifica e legge la differenza tra esso e il suo genitore. Questo rende efficace una patch. Quindi applica questa patch al ramo attualmente ritirato.

Nel tuo caso, il commit conteneva l'aggiunta di altre funzionalità. È possibile controllare due volte che il messaggio di commit corrisponde a quello che si pensava la funzione era guardando la patch che questo commettono genererebbe con git log:

git log -p -1 <sha1-of-your-commit>

Il -p dice il login per mostrare non solo le informazioni commettere come autore, data e messaggio di commit, ma per includere anche la patch (o la differenza) introdotta dal commit. L'opzione -1 dice a git log di interrompere la cronologia degli elenchi dopo 1 commit.

fonte

2011-10-18 07:01:37

Grazie per la risposta. Ho controllato il registro. È esattamente quello che voglio Ma dopo aver eseguito git cherry-pick, ha aggiunto codici extra non in quel commit. E FYI, il commit in branch1 è stato unito da altri rami di sviluppo, questo forse causa questo problema? – Rocky

il codice era nel tuo ramo. esegui 'git log -p -1' sul ramo che hai selezionato per vedere cosa è stato aggiunto. Se il materiale extra non è lì, significa che esisteva già in quel ramo. Per verificare quale commit ha aggiunto un pezzo di codice, 'git log -Ssometextfromafeature' mostrerà cosa ha aggiunto quel codice. –

Ho anche incontrato questo comportamento ... ho rintracciato verso il basso per la seguente spiegazione, ma forse qualcuno chiarire questo un più:

È ciliegia scegliere un commit, il commit contiene 1 cambiare in 1 file di
si nota che non solo il cambiamento contenuto nel commettono, ma (sono compresi per lo più intorno a che il cambiamento) anche più cambiamenti

Questo perché il cambiamento nel commettere dipende da un cambiamento precedente. Quindi quest'area di codice è stata modificata più volte dopo che è stato creato il ramo di destinazione che si desidera selezionare.

Git torna nella cronologia fino a quando la sorgente di selezione della ciliegia corrisponde alla destinazione e crea la patch in base a questa revisione. Ecco perché potrebbero apparire più cambiamenti ...

Trovo questo comportamento un po 'paura, perché ci si aspetterebbe che solo le modifiche dalla data di hash commettere vengono raccolte

fonte

2013-09-25 09:38:12 Wirtsi

Perché la selezione con selezione rapida modifica più di un commit?

risposta

Problemi correlati