2011-11-24 30 views
5

Ho un albero git che è simile al seguente:Git rebase commettere selezione

enter image description here

A causa della revisione strumento che usiamo, noi raccogliamo ciliegia cambiamenti in piuttosto che alla loro fusione. Questo ci lascia con alcuni duplicati logici, il cui ramo ho quindi appena eliminato. Ad esempio, la modifica sotto ssl_tests "Modifica: Modifica nome ..." può essere visualizzata anche in dev.

Ora, forse questa è una mancanza di comprensione da parte mia di cherry pick, ma questi commit hanno hash diversi e quindi sono diversi commit giusto? Anche se sono logicamente uguali.

Tuttavia, quando vado a rebase ssl_tests su dev, git riesce a capire che quei commit selezionati da cherry sono upstream e quindi rebases solo il commit "New Feature: Unit tests ..." da ssl_tests.

Come al solito, con git, questo è fantastico! Questo è esattamente quello che voglio! La mia domanda però, è come fa a capire che non ha bisogno di ribaltare gli altri commit se hanno hash diversi?

Grazie! Stephen

+0

Un buon post sull'unione della magia in Git è [Come e/o perché si fondono in Git meglio che in SVN?] (Http://stackoverflow.com/q/2471606/11343) – CharlesB

risposta

5

Git sta esaminando più di un semplice SHA1 qui. In realtà sta prendendo in considerazione il contenuto del commit. Vede che gli alberi risultanti dall'applicazione del commit e non applicando il commit sono uguali; cioè, il commit sarebbe vuoto se applicato alla nuova base. Quindi, rebase è abbastanza intelligente da sapere che non deve preoccuparsi di includere quei commit.