often - Diferencia entre git pull y git pull--rebase

git rebase tutorial (5)

A veces tenemos un canal ascendente que redistribuye / rebobina una rama de la que dependemos. Esto puede ser un gran problema, causando conflictos confusos para nosotros si estamos en una etapa posterior.
La magia es git pull --rebase
En términos generales, un impulso normal de git es algo así (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, podrías pensar que un git pull --rebase hace justamente esto:
git fetch origin git rebase origin/foo
Pero eso no ayudará si la rebase ascendente implicaba algún "aplastamiento" (lo que significa que los identificadores de parches de las confirmaciones cambiaron, no solo su orden).
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 tiempo pasa, y has hecho algunas confirmaciones sobre tu propio "foo":
a---b---c---d---e---p---q---r (foo)
Mientras tanto, en un ataque de furia antisocial, el mantenedor ascendente no solo ha rebasado su "foo", sino que incluso utilizó 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 resultaría en un caos. Incluso un git ir a buscar; git rebase origin / foo no lo cortaría, porque cometer "b" y "c" en un lado, y cometer "b + c" en el otro, entraría en conflicto. (Y de manera similar con d, e, yd + e).
Lo que hace git pull --rebase , 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 / 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):
gitolite.com/git-pull--rebase

Comencé a usar git hace un tiempo 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: solo hace un pull.

Por favor ayúdame a entender la diferencia.

En el caso más simple de no colisiones.

con rebase: rebasa sus confirmaciones locales en la parte superior del HEAD remoto y no crea una confirmación de combinación / fusión
sin / normal: fusiona y crea un commit de mezcla

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 combinar los cabezales de rama recuperados 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 rebases son cómo los cambios deberían pasar de la parte superior de la jerarquía hacia abajo y las combinaciones son la forma en que fluyen hacia arriba

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

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á ningún 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

git pull = git fetch + git merge con el seguimiento de la rama en sentido ascendente

git pull --rebase = git fetch + git rebase contra el seguimiento de la rama en sentido ascendente

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