Diferencia entre git pull y git pull --rebase

Comencé a usar git en algún momento y no entiendo completamente las complejidades. Mi pregunta básica aquí es averiguar la diferencia entre una git pully git pull --rebase, dado que la adición de la --rebaseopción no parece que hacer algo muy diferente: sólo lo hace un tirón.

Por favor, ayúdame a entender la diferencia.

git pull= git fetch+ git mergecontra el seguimiento de la rama aguas arriba

git pull --rebase= git fetch+ git rebasecontra el seguimiento de la rama aguas arriba

Si quieres saber cómo git mergey git rebasediferir, lee esto .

A veces tenemos un flujo ascendente que rebase / rebobina una rama de la que dependemos. Esto puede ser un gran problema, ya que nos genera conflictos desordenados si estamos aguas abajo.

La magia es git pull --rebase

Un git pull normal es, en términos generales, algo como esto (usaremos un origen remoto llamado y una rama llamada foo en todos estos ejemplos):

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

A primera vista, puede pensar que un git pull --rebase hace exactamente esto:

git fetch origin
git rebase origin/foo

Pero eso no ayudará si el rebase ascendente involucró algún "aplastamiento" (lo que significa que los identificadores de parche de los commits cambiaron, no solo su orden).

Lo que significa git pull --rebase tiene que hacer un poco más que eso. Aquí hay una explicación de lo que hace y cómo.

Digamos que su punto de partida es este:

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

El tiempo pasa, y has hecho algunas confirmaciones además de tu propio "foo":

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

Mientras tanto, en un ataque de rabia antisocial, el mantenedor corriente arriba no solo ha rebajado su "foo", sino que incluso usó una calabaza o dos. Su cadena de compromiso ahora se ve así:

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

Un tirón git en este punto daría lugar al caos. Incluso una git fetch; git rebase origin / foo no lo cortaría, porque comete "b" y "c" por un lado, y comete "b + c" por el otro, entraría en conflicto. (Y de manera similar con d, e, y d + e).

Lo git pull --rebaseque, en este caso, es:

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

Esto te da:

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

Aún puede obtener conflictos, pero serán conflictos genuinos (entre p / q / r y a / b + c / d + e / f), y no conflictos causados ​​por b / c en conflicto con b + c, etc.

Respuesta tomada de (y ligeramente modificada):
http://gitolite.com/git-pull--rebase

Supongamos que tiene dos confirmaciones en la sucursal local:

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

Después de "git pull", será:

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

Después de "git pull --rebase", no habrá punto de fusión G. Tenga en cuenta que D y E se convierten en confirmaciones diferentes:

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

En el caso más simple de no colisiones

• con rebase: reajusta sus confirmaciones locales en la parte superior de HEAD remoto y no crea una confirmación de fusión / fusión
• sin / normal: combina y crea una confirmación de fusión

Ver también:

man git-pull

Más precisamente, git pull ejecuta git fetch con los parámetros dados y llama a git merge para fusionar las cabezas de rama recuperadas en la rama actual. Con --rebase, ejecuta git rebase en lugar de git merge.

Ver también: ¿
Cuándo debo usar git pull --rebase?
http://git-scm.com/book/en/Git-Branching-Rebasing

Para esto es importante entender la diferencia entre Merge y Rebase.

Las bases son cómo deben pasar los cambios desde la parte superior de la jerarquía hacia abajo y las fusiones son cómo fluyen hacia arriba.

Para más detalles, consulte: http://www.derekgourlay.com/archives/428