Diferencia entre git pull y git pull –rebase

Empecé a usar git alguna vez y no entiendo completamente las complejidades. Mi pregunta básica aquí es descubrir la diferencia entre un git pull y un git pull --rebase , ya que agregar la opción --rebase no parece hacer algo muy diferente: simplemente hace un pull.

Por favor, ayúdame a entender la diferencia.

git pull = git fetch + git merge contra el seguimiento de la twig upstream

git pull --rebase = git fetch + git rebase contra el seguimiento de la twig ascendente

Si quieres saber cómo difieren git merge y git rebase , lee esto .

A veces tenemos un flujo ascendente que rebase / rebobine una twig de la que dependemos. Esto puede ser un gran problema, causar conflictos confusos para nosotros si estamos aguas abajo.

La magia es git pull --rebase

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

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

A primera vista, podrías pensar que un git pull –rebase hace esto:

 git fetch origin git rebase origin/foo 

Pero eso no será de ayuda si la rebase cadena arriba implicó cualquier "aplastamiento" (lo que significa que los identificadores de parche de las confirmaciones cambiaron, no solo su order).

Lo que significa que 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 time pasa, y has hecho algunos commits encima de tu propio "foo":

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

Mientras tanto, en un ataque de furia antisocial, el mantenedor de aguas arriba no solo ha networkingefinido su "foo", sino que incluso usó uno o dos squash. Su cadena de compromiso ahora se ve así:

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

Un git pull en este punto resultaría en un caos. Incluso un gulp de git; git rebase origin / foo no lo cortaría, porque comete "b" y "c" en un lado, y comete "b + c" en el otro, entraría en conflicto. (Y de manera similar con d, e, y d + e).

Lo que git pull --rebase hace, 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 tener conflictos, pero serán conflictos genuinos (entre p / q / ry 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 una 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á ningún punto de fusión G. Tenga en count que D y E se convierten en diferentes commits:

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

En el caso más simple de no colisiones

  • con rebase: rebases tus commits locales ontop de HEAD remoto y no crea un commit de merge / merge
  • sin / normal: se fusiona y crea un compromiso de fusión

Ver también:

man git-pull

Más precisamente, git pull ejecuta git fetch con los parameters dados y llama a git merge para fusionar los encabezados de las twigs recuperadas en la twig actual. Con –rebase, ejecuta git rebase en lugar de git merge.

Ver también:
¿Cuándo debería usar git pull –rebase?
http://git-scm.com/book/es/Git-Branching-Rebasing

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

Las rebases son cómo los cambios deberían pasar desde la parte superior de la jerarquía hacia abajo y las fusiones son la forma en que fluyen hacia arriba.

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