¿Qué sucede cuando 'git pull –rebase origen de desarrollo' desde dentro de una twig de características?

Digamos que tengo una twig de características llamada FeatureA , y no está sincronizada con el development (remoto) en el que está basado. Normalmente, rebase mi twig llamando git rebase development (después de sincronizar mi desarrollo local con el origin/development naturalmente).

Hoy en día, lo hago diferente y llamo a git pull --rebase origin development de mi twig de características. Ahora, ¿cuál es la diferencia?

Solutions Collecting From Web of "¿Qué sucede cuando 'git pull –rebase origen de desarrollo' desde dentro de una twig de características?"

git pull --rebase origin development es un acceso directo a estos commands:

 git fetch origin development git rebase origin/development 

Es decir, search origin/development y luego volver a establecer la base de la twig actual encima de él.

ACTUALIZAR

Como @torek señaló:

Sí, excepto que la versión de dos arguments de fetch no actualiza origen / desarrollo en git 1.8.3 o anterior. (El resultado de rebase es el mismo, pero el origen / desarrollo no se mueve).

Versión corta: si la rebase funciona bien, funciona bien. Si no, todavía funciona tan bien como debería, podría ser un poco confuso en un visor gráfico.


Como siempre, git pull es básicamente git fetch seguido de … bueno, en este caso, git rebase lugar de git merge . Asi que:

  • search de origin
  • search solo la twig de development y poner eso en FETCH_HEAD
  • luego, en lugar de git merge <commit-ID-from-FETCH_HEAD> , usa git rebase con esa ID

Así que digamos que el gráfico de confirmación en su tree local se ve así (asumiremos que ejecutó una git fetch en algún punto del origin/development actualizado con sus confirmaciones E y F ):

  C - D <-- FeatureA / A - B <-- development \ E - F <-- origin/development 

Y, supongamos además que en origin , hay una confirmación más ahora en su twig llamada development . El paso fetch -from-origin lo levantará y hará que FETCH_HEAD apunte a eso, así que vamos a dibujarlo como nodo G :

  C - D <-- FeatureA / A - B <-- development \ E - F <-- origin/development \ G <-- FETCH_HEAD 

(Si su git es lo suficientemente nuevo, 1.8.4 o posterior, el origin/development también se actualizará en este momento, para apuntar al nodo G Si no, su copy local de su development , almacenada en su origin/development , queda rezagada . Realmente no importará la rebase, simplemente cambiará la forma en que verá los resultados en una vista de git log --graph o en un visor de tree de confirmación gráfico.)

Ahora la rebase copyrá tus commits de FeatureA en el método habitual para una rebase, y hará que FeatureA apunte a las copys, abandonando las confirmaciones originales. Llamaremos a los reestadificados C' y D' :

  C - D [abandoned] / A - B <-- development \ E - F <-- origin/development \ G <-- FETCH_HEAD \ C' - D' <-- FeatureA 

Si ejecuta una git fetch simple de git fetch en este punto, o si tiene el git más nuevo para que el origin/development haya movido; y si soltamos las partes "abandonadas" y simplificamos el dibujo, se convierte en:

 A - B <-- development \ E - F - G <-- origin/development \ C' - D' <-- FeatureA 

Si avanza rápidamente, fusione el development label de sucursal local para que coincida con el origin/development , es incluso más sencillo dibujar (baje la curvatura de B a E y coloque el development y el origin/development a la derecha de la flecha apuntando a G )