Herramientas

Cómo crear una nueva rama en Git con solo algunos cambios de otra rama

Al trabajar con Git en algunas situaciones puede surgir la necesidad de crear una nueva rama en Git que incluya solo algunos cambios de otra rama. Por ejemplo, si solo se necesita aplicar algunos cambios y no todos los realizados en la rama de desarrollo. Lo que se puede conseguir con comandos como git cherry-pick, git checkout y git diff. En esta entrada se explicará cómo realizar la creación de una nueva rama en Git con solo algunos cambios de otra rama

¿Por qué crear una nueva rama en Git con solo algunos cambios?

La capacidad de seleccionar cambios específicos y trasladarlos a una nueva rama es característica que puede facilitar la tarea de desarrollo en múltiples escenarios:

  1. Entrega de características específicas: Cuando se necesita entregar una funcionalidad parcial sin incluir el resto de los cambios en la rama.
  2. Solución de errores críticos: Aplicar una corrección importante sin afectar el resto de los desarrollos en curso.
  3. Preparación para revisiones o pruebas: Crear una versión con cambios seleccionados para revisión o pruebas específicas.
  4. Separación del trabajo en curso: Mantener un control más detallado dividiendo el trabajo en ramas más pequeñas.

Git ofrece herramientas como git cherry-pick, git checkout y git diff que permiten realizar estas tareas de manera eficiente y sin complicaciones.

Paso 1: Identificar el punto base para la nueva rama en Git

El primer paso para crear una nueva rama en Git con solo algunos cambios es identificar el commit base. Este commit será el punto de partida para la nueva rama. Puede ser:

  • El último commit en una rama principal, como main o master.
  • Un commit específico en la rama actual donde se hubiese publicado el trabajo por última vez.

Para identificar el commit base se puede recurrir al comando: git log --oneline, lo que mostrará un historial resumido de commits. Supóngase que el historial del repositorio es como el que se muestra a continuación:

a1b2c3d Cambios en funcionalidad X 
e4f5g6 Corrección de bug Y 
h7i8j9 Implementación de nueva característica Z 

Si el commit base es aquelarre en la que se corrige el bug Y será necesario anotar su has, en este caso e4f5g6.

Paso 2: Crear una nueva rama en Git desde el punto base

Ahora, será necesario crear una nueva rama utilizando el hash del commit base identificado en el paso anterior:

git checkout -b nueva-rama e4f5g6

Este comando:

  • Crea una nueva rama llamada nueva-rama.
  • Posiciona el HEAD en el commit base (e4f5g6 en este caso).

Paso 3: Seleccionar y aplicar los cambios necesarios

Una vez creada la nueva rama, el siguiente paso será traer únicamente los cambios necesarios de otra rama. Dependiendo de cómo estén organizados los cambios, se puede usar uno de los siguientes métodos:

Método 1: Usar git cherry-pick para aplicar commits específico

Si los cambios requeridos están en commits separados, la mejor opción es usar git cherry-pick. Para eso se debe seguir los siguientes pasos:

  1. Cambiar a la nueva rama:
   git checkout nueva-rama
  1. Aplica los commits seleccionados:
   git cherry-pick <hash_commit_1> <hash_commit_2>

Por ejemplo:

   git cherry-pick h7i8j9 a1b2c3d
  1. Verificar el historial:
   git log

Método 2: Usar git checkout para extraer archivos específicos

Por otro lado, si los cambios están distribuidos en archivos específicos, una opción sería utilizar el comando git checkout. Esto podría indicar que los commits no son atómicos, es decir, no contienen un único cambio bien definido. En este caso, sería recomendable revisar la metodología utilizada para crear los commits en Git. No obstante, si esta situación es inevitable, se puede proceder siguiendo los pasos que se detallan a continuación:”

  1. Cambiar a tu nueva rama:
   git checkout nueva-rama
  1. Traer los archivos necesarios:
   git checkout <rama_original> -- ruta/del/archivo

Por ejemplo:

   git checkout desarrollo -- src/app.js
  1. Hacer un commit para guardar los cambios:
   git add ruta/del/archivo
   git commit -m "Traer cambios específicos desde desarrollo"

Método 3: Usar git diff y git apply para cambios personalizados

Finalmente, si lo que se necesita es incluir solo algunos cambios de un archivo el proceso es algo más complejo, pero también se puede hacer. Los pasos para seguir en este caso son:

  1. Generar un parche en la rama original:
   git diff desarrollo -- ruta/del/archivo > cambios.patch
  1. Cambiar a la nueva rama:
   git checkout nueva-rama
  1. Aplicar el parche:
   git apply cambios.patch
  1. Realizar el commit:
   git add ruta/del/archivo
   git commit -m "Aplicar cambios seleccionados desde parche"

Paso 4: Verificar los cambios en la nueva rama

Antes de subir la nueva rama, es necesario asegurarse de que todo es correcto. Para lo que se deben seguir los siguientes pasos:

  1. Verificar los archivos modificados:
   git status
  1. Revisar el historial de commits:
   git log

Paso 5: Subir la nueva rama a un repositorio remoto

Finalmente, para compartir la nueva rama con el resto del equipo, será necesario subirla al repositorio remoto:

git push origin nueva-rama

Conclusiones

Crear una nueva rama en Git con solo algunos cambios es una tarea común que se puede manejar fácilmente con herramientas como git cherry-pick, git checkout y git diff. Este proceso permite entregar funcionalidades específicas, solucionar errores críticos o preparar versiones para pruebas sin afectar el resto del trabajo en desarrollo.

Nota: La imagen de este artículo fue generada utilizando un modelo de inteligencia artificial.

¿Te ha parecido de utilidad el contenido?

Daniel Rodríguez

Share
Published by
Daniel Rodríguez
Tags: Git

Recent Posts

Curiosidad: De dónde vienen foo, bar y foobar

Si revisáis código o documentación de otros programadores, tarde o temprano os toparéis con dos…

5 días ago

BG/NBD + Gamma/Gamma: el modelo probabilístico para CLV en compras continuas

Los dos artículos anteriores cubrieron el CLV clásico —una fórmula útil pero que trata a…

7 días ago

Errores habituales al trabajar con DataFrames grandes en Pandas (y cómo evitarlos)

Hay un momento muy concreto en la vida de casi todo análisis: el código que…

2 semanas ago

Champion vs Challenger: Cómo los Bancos Validan Modelos Nuevos antes de Ponerlos en Producción

Has construido un nuevo modelo de credit scoring. Las métricas de validación son mejores que…

2 semanas ago

Cómo Comparar Dos Hipotecas con Todos los Gastos Incluidos

Comparar dos hipotecas parece sencillo: la que tenga el TIN más bajo es la mejor…

3 semanas ago

Segmentación RFM: cómo clasificar tu cartera de clientes antes de calcular el CLV

En un artículo anterior vimos la fórmula clásica del CLV junto a sus limitaciones. Una…

3 semanas ago

This website uses cookies.