Rebasing es el proceso de mover o combinar una secuencia de confirmaciones a una nueva confirmación base. El cambio de base es más útil y se visualiza fácilmente en el contexto de un flujo de trabajo de ramificación de características. El proceso general se puede visualizar de la siguiente manera:

desde una perspectiva de contenido, rebasing es cambiar la base de tu rama de un commit a otro haciendo que parezca como si hubieras creado tu rama a partir de un commit diferente., Internamente, Git logra esto creando nuevas confirmaciones y aplicándolas a la base especificada. Es muy importante entender que aunque la rama tenga el mismo aspecto, está compuesta de commits completamente nuevos.

uso

la razón principal para el cambio de base es mantener un historial de proyecto lineal. Por ejemplo, considere una situación en la que la rama maestra ha progresado desde que comenzó a trabajar en una rama de características., Desea obtener las últimas actualizaciones de la rama master en su rama feature, pero desea mantener limpio el historial de su rama para que parezca que ha estado trabajando con la última rama master. Esto le da el beneficio posterior de una fusión limpia de su rama de características de nuevo en la rama principal. ¿Por qué queremos mantener una «historia limpia»? Los beneficios de tener un historial limpio se vuelven tangibles al realizar operaciones de Git para investigar la introducción de una regresión. Un escenario más real sería:

1. Se identifica un error en la rama maestra., Una característica que estaba funcionando con éxito ahora está rota.
2. Un desarrollador examina el historial de la rama maestra usando git log debido al» historial limpio», el desarrollador puede razonar rápidamente sobre el historial del proyecto.
3. El desarrollador no puede identificar cuándo se introdujo el error usando git log por lo que el desarrollador ejecuta un git bisect.
4. Debido a que el historial de git está limpio, git bisect tiene un conjunto refinado de confirmaciones para comparar cuando se busca la regresión., El desarrollador encuentra rápidamente la confirmación que introdujo el error y es capaz de actuar en consecuencia.

Obtenga más información sobre git log y git bisect en sus páginas de uso individuales.

Tiene dos opciones para integrar su característica en la rama maestra: fusionar directamente o rebasear y luego fusionar. La primera opción resulta en una fusión de 3 vías y una confirmación de fusión, mientras que la segunda resulta en una fusión de avance rápido y un historial perfectamente lineal. El siguiente diagrama muestra cómo el rebase en la rama master facilita una fusión de avance rápido.,

Rebasing es una forma común de integrar los cambios de upstream en su repositorio local. Introducir los cambios de upstream con Git merge resulta en una confirmación de merge superflua cada vez que quieres ver cómo ha progresado el proyecto. Por otro lado, rebasing es como decir, «quiero basar mis cambios en lo que todo el mundo ya ha hecho.»

no rebase el historial público

Como hemos comentado anteriormente en reescribir el historial, nunca debe rebase las confirmaciones una vez que se hayan enviado a un repositorio público., La rebase reemplazaría las confirmaciones antiguas por otras nuevas y parecería que esa parte del historial de tu proyecto desapareció abruptamente.

git Rebase Standard vs git Rebase Interactive

git rebase interactive es cuando git rebase acepta un argumento -- i. Esto significa » interactivo.»Sin ningún argumento, el comando se ejecuta en modo estándar. En ambos casos, supongamos que hemos creado una rama de características separada.,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

Git rebase en modo estándar tomará automáticamente las confirmaciones en su rama de trabajo actual y las aplicará al encabezado de la rama pasada.

 git rebase 

Esto automáticamente reajusta la rama actual en , que puede ser cualquier tipo de cometer referencia (por ejemplo un ID, un nombre de rama, una etiqueta, o una referencia relativa a HEAD).

ejecutandogit rebase con el indicador-i comienza una sesión de cambio de base interactiva., En lugar de mover ciegamente todos los commits a la nueva base, el rebasing interactivo te da la oportunidad de alterar los commits individuales en el proceso. Esto le permite limpiar el historial eliminando, dividiendo y alterando una serie existente de confirmaciones. Es como Git commit --amend en esteroides.

 git rebase --interactive 

Este reajusta la rama actual en pero utiliza un sistema interactivo de reajuste de la sesión. Esto abre un editor donde puede introducir comandos (descritos a continuación) para cada confirmación que se va a cambiar de base., Estos comandos determinan cómo se transferirán las confirmaciones individuales a la nueva base. También puedes reordenar la lista de confirmaciones para cambiar el orden de las confirmaciones. Una vez que hayas especificado comandos para cada confirmación en la rebase, Git comenzará a reproducir confirmaciones aplicando los comandos de rebase. Los comandos de edición de rebase son los siguientes:

comandos de rebase adicionales

como se detalla en la página Historial de reescritura, el rebase se puede usar para cambiar confirmaciones anteriores y múltiples, archivos confirmados y mensajes múltiples., Si bien estas son las aplicaciones más comunes, git rebase también tiene opciones de comandos adicionales que pueden ser útiles en aplicaciones más complejas.

• git rebase -- d significa que durante la reproducción la confirmación será descartada del bloque de confirmación combinado final.
• git rebase -- p deja la confirmación como está. No modificará el mensaje o contenido del commit y seguirá siendo un commit individual en el historial de ramas.
• git rebase -- x durante la reproducción ejecuta un script de shell de línea de comandos en cada confirmación marcada., Un ejemplo útil sería ejecutar el conjunto de pruebas de su base de código en confirmaciones específicas, lo que puede ayudar a identificar regresiones durante un rebase.

Recap

el rebase interactivo te da un control completo sobre cómo se ve el historial de tu proyecto. Esto ofrece mucha libertad a los desarrolladores, ya que les permite cometer un historial «desordenado» mientras están enfocados en escribir código, luego regresar y limpiarlo después del hecho.

a la mayoría de los desarrolladores les gusta usar una rebase interactiva para pulir una rama de características antes de fusionarla en la base de código principal., Esto les da la oportunidad de aplastar las confirmaciones insignificantes, eliminar las obsoletas y asegurarse de que todo lo demás esté en orden antes de comprometerse con el historial «oficial» del proyecto. Para todos los demás, parecerá que toda la característica se desarrolló en una sola serie de confirmaciones bien planificadas.

el poder real del rebase interactivo se puede ver en el historial de la rama maestra resultante. Para todos los demás, parece que eres un desarrollador brillante que implementó la nueva característica con la cantidad perfecta de Confirmaciones la primera vez., Así es como el rebase interactivo puede mantener la historia de un proyecto limpia y significativa.

opciones de configuración

hay algunas propiedades de rebase que se pueden establecer usando git config. Estas opciones alterarán la apariencia de salida git rebase.

• rebase.stat : un booleano que está establecido en false de forma predeterminada. La opción alterna la visualización del contenido de diffstat visual que muestra lo que ha cambiado desde la última degradación.

• rebase.autoSquash: Un valor booleano que alterna el --autosquash comportamiento.,

• rebase.missingCommitsCheck: se puede establecer a múltiples valores que cambian el comportamiento de rebase alrededor de confirmaciones faltantes.,/tr>
  

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Cuando en git rebase --onto mode el comando se expande a:

    git rebase --onto 

  el comando --onto habilita una forma o rebase más poderosa que permite pasar referencias específicas para ser las puntas de una rebase.
  digamos que tenemos un repo de ejemplo con ramas como:

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureB se basa en featureA, sin embargo, nos damos cuenta de que featureB no depende de ninguno de los cambios en featureA y podría ramificarse de master.

    git rebase --onto master featureA featureB 

  asi es ., master se convierte en y featureB es referencia de lo HEAD del va a apuntar. Los resultados son:

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  comprender los peligros de rebase

  Una advertencia a tener en cuenta cuando se trabaja con Git Rebase es que los conflictos de fusión pueden ser más frecuentes durante un flujo de trabajo de rebase. Esto ocurre si tienes una rama de larga vida que se ha desviado del maestro., Eventualmente querrá rebase contra master y en ese momento puede contener muchas confirmaciones nuevas con las que los cambios de su rama pueden entrar en conflicto. Esto se soluciona fácilmente rebasando tu rama con frecuencia contra master, y haciendo confirmaciones más frecuentes. Los argumentos de la línea de comandos --continue y --abort se pueden pasar a git rebase para avanzar o restablecer la rebase cuando se trate de conflictos.

  una advertencia de rebase más seria es perder commits de reescritura de historia interactiva., Ejecutar rebase en modo interactivo y ejecutar subcomandos como squash o drop eliminará las confirmaciones del registro inmediato de tu rama. A primera vista, esto puede parecer como si las confirmaciones se hubieran ido permanentemente. Usando git reflog estas confirmaciones pueden ser restauradas y toda la rebase puede ser deshecha. Para obtener más información sobre el uso de git reflog para encontrar confirmaciones perdidas, visite nuestra página de documentación de Git reflog.

  Git Rebase en sí no es seriamente peligroso., Los casos de peligro real surgen cuando se ejecuta la reescritura del historial de rebases interactivos y se fuerzan los resultados a una rama remota compartida por otros usuarios. Este es un patrón que debe evitarse, ya que tiene la capacidad de sobrescribir el trabajo de otros usuarios remotos cuando extraen.

  la Recuperación de aguas de reajuste

  Si otro usuario ha reajustado y fuerza empujó a la rama en la que está comprometiendo a, de un elemento git pull sobrescribirá cualquier compromete han basado en que la rama anterior con la punta, que era la fuerza empujó., Afortunadamente, usando git reflog puede obtener el reflog de la rama remota. En el reflog de la rama remota puede encontrar una referencia antes de que se rebase. Luego puede cambiar la base de su rama contra esa referencia remota utilizando la opción --onto como se discutió anteriormente en la sección aplicación de Rebase avanzada.

  Resumen

  En este artículo hemos cubierto git rebase uso. Discutimos casos de uso básicos y avanzados y ejemplos más avanzados., Algunos puntos clave de discusión son:

  • git rebase standard vs interactive modes
  • git rebase configuration options
  • git rebase onto onto
  • git rebase Lost commits