Differenza tra git pull e git pull --rebase

Ho iniziato a usare git qualche tempo fa e non capisco perfettamente le complessità. La mia domanda di base qui è scoprire la differenza tra a git pulle git pull --rebase, poiché l'aggiunta --rebasedell'opzione non sembra fare qualcosa di molto diverso: fa solo un tiro.

Per favore aiutami a capire la differenza.

git pull= git fetch+ git mergecontro il monitoraggio della diramazione a monte

git pull --rebase= git fetch+ git rebasecontro il monitoraggio della diramazione a monte

Se vuoi sapere come git mergee git rebasedifferire, leggi questo .

A volte abbiamo un upstream che ha rinnovato / riavvolto un ramo da cui dipendiamo. Questo può essere un grosso problema - causando conflitti disordinati per noi se siamo a valle.

La magia è git pull --rebase

Un normale git pull è, in termini vaghi, qualcosa del genere (useremo un telecomando chiamato origin e un ramo chiamato foo in tutti questi esempi):

# assume current checked out branch is "foo"
git fetch origin
git merge origin/foo

A prima vista, potresti pensare che un git pull --rebase faccia proprio questo:

git fetch origin
git rebase origin/foo

Ma ciò non sarà d'aiuto se il rebase upstream implicasse qualche "schiacciamento" (il che significa che i patch-id degli commit sono cambiati, non solo il loro ordine).

Ciò significa che git pull --rebase deve fare un po 'di più. Ecco una spiegazione di cosa fa e come.

Diciamo che il tuo punto di partenza è questo:

a---b---c---d---e  (origin/foo) (also your local "foo")

Il tempo passa e hai fatto alcuni commit in cima al tuo "pippo":

a---b---c---d---e---p---q---r (foo)

Nel frattempo, in un impeto di rabbia antisociale, il manutentore a monte non ha solo riformato il suo "foo", ma ha anche usato uno o due squash. La sua catena di commit ora appare così:

a---b+c---d+e---f  (origin/foo)

A questo punto un tiro di sbalzo provocherebbe il caos. Perfino un git fetch; git rebase origin / foo non lo taglierebbe, perché commette "b" e "c" da un lato e commettere "b + c" dall'altro, sarebbe in conflitto. (E allo stesso modo con d, e, d + e).

Cosa git pull --rebasesignifica, in questo caso,:

git fetch origin
git rebase --onto origin/foo e foo

Questo ti dà:

 a---b+c---d+e---f---p'---q'---r' (foo)

Potresti ancora avere conflitti, ma saranno veri e propri conflitti (tra p / q / r e a / b + c / d + e / f) e non conflitti causati da b / c in conflitto con b + c, ecc.

Risposta tratta da (e leggermente modificata):
http://gitolite.com/git-pull--rebase

Supponiamo di avere due commit nella filiale locale:

      D---E master
     /
A---B---C---F origin/master

Dopo "git pull", sarà:

      D--------E  
     /          \
A---B---C---F----G   master, origin/master

Dopo "git pull --rebase", non ci sarà nessun punto di unione G. Nota che D ed E diventano diversi commit:

A---B---C---F---D'---E'   master, origin/master

Nel caso più semplice senza collisioni

• con rebase: ripristina il commit locale in cima a HEAD remoto e non crea un commit merge / merge
• senza / normale: unisce e crea un commit di unione

Guarda anche:

man git-pull

Più precisamente, git pull esegue git fetch con i parametri indicati e chiama git merge per unire le teste di ramo recuperate nel ramo corrente. Con --rebase, esegue git rebase invece di git merge.

Vedi anche:
Quando dovrei usare git pull --rebase?
http://git-scm.com/book/en/Git-Branching-Rebasing

Per questo è importante capire la differenza tra Merge e Rebase.

I riposizionamenti sono come i cambiamenti dovrebbero passare dall'alto verso il basso della gerarchia verso il basso e le fusioni sono come rifluiscono verso l'alto.

Per i dettagli, consultare: http://www.derekgourlay.com/archives/428