0Pricing
DevOps Bootcamp · Lección

Rebase frente a merge

Compare el rebase y el merge, y aprenda cuándo usar cada uno para mantener un historial limpio y lineal.

Rebase frente a merge es una lección gratuita de DevOps Bootcamp en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de DevOps Bootcamp, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de DevOps Bootcamp incluye 4 lecciones en total.

¿Fusionar o hacer rebase? La elección

Al trabajar con Git, a menudo una de sus ramas diverge de otra, como su rama feature de main.

¿Cómo puede combinar esos cambios? Git ofrece dos estrategias principales: fusionar y hacer rebase. Ambas permiten integrar cambios, pero lo hacen de maneras fundamentalmente diferentes, lo que da lugar a historiales de proyecto distintos.

Fusionar: combinar historiales

Fusionar es la forma predeterminada de Git para integrar cambios. Cuando fusiona una rama con otra, Git toma el contenido de la rama de origen y lo combina con la rama de destino.

La característica principal de una fusión es que crea una nueva confirmación de fusión. Esta confirmación tiene dos confirmaciones principales, lo que muestra explícitamente que se unieron dos historiales divergentes. Conserva el historial exacto de ambas ramas.

Realizar una fusión en Git

Veamos una fusión sencilla. Crearemos una rama feature, añadiremos una confirmación y después la fusionaremos de nuevo con main.

git init my_merge_project
cd my_merge_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature A" >> feature.txt
git add .
git commit -m "Add feature A"

git checkout main
echo "Main update" >> main.txt
git add .
git commit -m "Update main"

git merge feature

git log --oneline --graph

Fusión: ventajas y desventajas

Fusionar es sencillo y seguro para las ramas compartidas, pero puede generar un historial «desordenado».

  • Ventajas:
  • Conserva el historial exacto de las confirmaciones.
  • No es destructivo: no reescribe las confirmaciones existentes.
  • Es sencillo de usar y entender.
  • Desventajas:
  • Puede crear un historial «ruidoso» con muchas confirmaciones de fusión.
  • El grafo puede parecer complejo cuando se fusionan muchas ramas.

Rebase: reescribir el historial

Hacer rebase es una alternativa a fusionar que integra los cambios trasladando o combinando una secuencia de confirmaciones a una nueva confirmación base. En lugar de crear una confirmación de fusión, reescribe el historial del proyecto.

En esencia, las confirmaciones de su rama de funcionalidades se «reproducen» sobre la confirmación más reciente de la rama de destino, de modo que parece que comenzó a trabajar desde allí. Esto crea un historial lineal sin confirmaciones de fusión adicionales.

Realizar un rebase en Git

Ahora probemos el mismo escenario con rebase. Aplicaremos rebase a nuestra rama feature sobre main.

Observe cómo la confirmación de la rama feature se vuelve a aplicar sobre la confirmación más reciente de main; después, una fusión de avance rápido hace que main apunte a ella.

git init my_rebase_project
cd my_rebase_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature B" >> feature.txt
git add .
git commit -m "Add feature B"

git checkout main
echo "Main update 2" >> main.txt
git add .
git commit -m "Update main 2"

git checkout feature
git rebase main

git checkout main
git merge feature

git log --oneline --graph

Rebase: ventajas y desventajas

Hacer rebase crea un historial limpio, pero incluye una advertencia importante sobre las ramas compartidas.

  • Ventajas:
  • Crea un historial del proyecto limpio y lineal.
  • Facilita la navegación y la comprensión del historial de confirmaciones.
  • Permite limpiar las confirmaciones (combinarlas o reordenarlas) antes de integrarlas.
  • Desventajas:
  • Reescribe el historial de confirmaciones.
  • Puede ser peligroso si se aplica a confirmaciones que ya se han enviado a un repositorio remoto compartido (público).

Fusión frente a rebase: comparación

Aquí tiene un resumen rápido de las diferencias principales:

  • Fusión:
  • Crea una nueva confirmación de fusión.
  • Conserva el historial completo y exacto.
  • No es destructiva.
  • El grafo puede ser complejo.
  • Rebase:
  • Reescribe el historial y no crea una confirmación de fusión.
  • Da como resultado un historial lineal.
  • Es destructivo (altera los identificadores de las confirmaciones).
  • El grafo es muy limpio.

Elegir su estrategia

Entonces, ¿cuándo debería utilizar cada una?

  • Utilice la fusión cuando:
  • Trabaje con ramas públicas o compartidas (por ejemplo, main o develop).
  • Necesite conservar el historial exacto del proyecto.
  • Quiera mostrar explícitamente cuándo se combinaron historiales divergentes.
  • Utilice rebase cuando:
  • Trabaje en su rama de funcionalidades privada antes de enviarla.
  • Quiera un historial limpio y lineal.
  • Quiera organizar las confirmaciones de su rama de funcionalidades (por ejemplo, combinarlas o reordenarlas) antes de integrarla.

La regla de oro: ¡no haga nunca rebase de confirmaciones que ya se hayan enviado a un repositorio remoto compartido! Hacer rebase del historial compartido puede causar grandes problemas a sus colaboradores.

Comprobación rápida: ¿fusionar o hacer rebase?

Considere las características de las dos estrategias principales de integración de Git.

Repaso: fusión frente a rebase

En esta lección, hemos explorado las dos formas fundamentales de Git para integrar cambios: fusionar y hacer rebase.

  • Fusionar combina los historiales mediante una nueva confirmación de fusión y conserva todas las confirmaciones originales.
  • Hacer rebase reescribe el historial y crea un flujo lineal al trasladar las confirmaciones.

Elija sabiamente según el flujo de trabajo de su equipo y recuerde la regla de oro: ¡no haga nunca rebase del historial público! Comprender esto es fundamental para mantener un flujo de trabajo de Git limpio y colaborativo.

Preguntas frecuentes

¿La lección «Rebase frente a merge» es gratis?

Sí — el texto completo de «Rebase frente a merge» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de DevOps Bootcamp, actualiza a CoddyKit PRO. El curso de DevOps Bootcamp incluye 4 lecciones en total.

¿Qué aprenderé en «Rebase frente a merge»?

Compare el rebase y el merge, y aprenda cuándo usar cada uno para mantener un historial limpio y lineal. Practicas DevOps Bootcamp con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar DevOps Bootcamp?

No se requiere experiencia previa. DevOps Bootcamp en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.

¿Cuánto tiempo toma la lección «Rebase frente a merge»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de DevOps Bootcamp?

Sí. Cada lección de DevOps Bootcamp incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Flujo de trabajo con ramas de funcionalidades
  2. Introducción al flujo de trabajo Gitflow
  3. Rebase frente a merge
  4. Desarrollo basado en trunk
← Volver a DevOps Bootcamp