Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Aprende Conceptos Básicos de Rebase | Flujos de Trabajo Más Avanzados
Fundamentos de GitHub
course content

Contenido del Curso

Fundamentos de GitHub

Fundamentos de GitHub

1. Introducción a GitHub
2. Interacción Básica con Remotos
3. Flujos de Trabajo Más Avanzados

book
Conceptos Básicos de Rebase

Realización de un commit en la rama main

Comenzar realizando un commit directamente en la rama remota main editando el archivo README.md en el repositorio remoto. Esto provocará que las ramas main y feature/payment tengan un historial de commits divergente.

Esta es la línea agregada al archivo:

Este es el mensaje de commit correspondiente:

Comprensión del Rebasing

Como mencionamos en el capítulo anterior, una vez que la rama feature ha sido revisada y probada, puede y debe fusionarse de nuevo en la rama main. Hasta ahora, solo hemos utilizado el comando git merge para este propósito. Sin embargo, otro enfoque es utilizar el comando git rebase.

Note
Estudiar más

Rebasing es el proceso de mover o combinar una secuencia de commits a un nuevo commit base. Esto se realiza reproduciendo los cambios de una rama sobre otra rama, lo que da como resultado un historial de commits lineal.

Cuando creamos una rama, Git rastrea el último commit en ambas ramas. Si solo una rama tiene cambios nuevos, Git puede avanzar rápidamente y aplicar los cambios. Sin embargo, si ambas ramas tienen cambios nuevos, Git crea un nuevo commit de fusión, lo que resulta en una fusión de tres vías.

Así es como se vería una fusión de tres vías en nuestro caso, donde C4 era el último commit en la rama feature/payment antes de fusionar:

Sin embargo, las fusiones de tres vías pueden complicar la depuración debido al historial dividido y no lineal. Al hacer un rebase, cambiamos la base de nuestros commits y los reproducimos sobre la nueva base, permitiendo que Git realice una fusión fast-forward y mantenga un historial lineal.

Aquí tienes una animación que ilustra cómo se puede realizar el rebase en nuestro caso (los identificadores de los commits no corresponden a los reales aquí):

Note
Nota

Cuando haces un rebase de una rama, en esencia estás reescribiendo su historial. Esto significa que los commits antiguos son reemplazados por nuevos, que tienen identificadores diferentes (suma hash) porque se basan en diferentes instantáneas del código. Como se muestra en la animación anterior, el identificador del commit en la rama feature/payment cambió después de hacer rebase.

question mark

¿Cuál es el propósito principal de usar git rebase en lugar de git merge?

Select the correct answer

¿Todo estuvo claro?

¿Cómo podemos mejorarlo?

¡Gracias por tus comentarios!

Sección 3. Capítulo 4

Pregunte a AI

expand

Pregunte a AI

ChatGPT

Pregunte lo que quiera o pruebe una de las preguntas sugeridas para comenzar nuestra charla

course content

Contenido del Curso

Fundamentos de GitHub

Fundamentos de GitHub

1. Introducción a GitHub
2. Interacción Básica con Remotos
3. Flujos de Trabajo Más Avanzados

book
Conceptos Básicos de Rebase

Realización de un commit en la rama main

Comenzar realizando un commit directamente en la rama remota main editando el archivo README.md en el repositorio remoto. Esto provocará que las ramas main y feature/payment tengan un historial de commits divergente.

Esta es la línea agregada al archivo:

Este es el mensaje de commit correspondiente:

Comprensión del Rebasing

Como mencionamos en el capítulo anterior, una vez que la rama feature ha sido revisada y probada, puede y debe fusionarse de nuevo en la rama main. Hasta ahora, solo hemos utilizado el comando git merge para este propósito. Sin embargo, otro enfoque es utilizar el comando git rebase.

Note
Estudiar más

Rebasing es el proceso de mover o combinar una secuencia de commits a un nuevo commit base. Esto se realiza reproduciendo los cambios de una rama sobre otra rama, lo que da como resultado un historial de commits lineal.

Cuando creamos una rama, Git rastrea el último commit en ambas ramas. Si solo una rama tiene cambios nuevos, Git puede avanzar rápidamente y aplicar los cambios. Sin embargo, si ambas ramas tienen cambios nuevos, Git crea un nuevo commit de fusión, lo que resulta en una fusión de tres vías.

Así es como se vería una fusión de tres vías en nuestro caso, donde C4 era el último commit en la rama feature/payment antes de fusionar:

Sin embargo, las fusiones de tres vías pueden complicar la depuración debido al historial dividido y no lineal. Al hacer un rebase, cambiamos la base de nuestros commits y los reproducimos sobre la nueva base, permitiendo que Git realice una fusión fast-forward y mantenga un historial lineal.

Aquí tienes una animación que ilustra cómo se puede realizar el rebase en nuestro caso (los identificadores de los commits no corresponden a los reales aquí):

Note
Nota

Cuando haces un rebase de una rama, en esencia estás reescribiendo su historial. Esto significa que los commits antiguos son reemplazados por nuevos, que tienen identificadores diferentes (suma hash) porque se basan en diferentes instantáneas del código. Como se muestra en la animación anterior, el identificador del commit en la rama feature/payment cambió después de hacer rebase.

question mark

¿Cuál es el propósito principal de usar git rebase en lugar de git merge?

Select the correct answer

¿Todo estuvo claro?

¿Cómo podemos mejorarlo?

¡Gracias por tus comentarios!

Sección 3. Capítulo 4
some-alt