En un flujo de trabajo con Git es común crear ramas nuevas para desarrollar funcionalidades específicas. Esto permite mantener el código organizado, probar cambios sin afectar la rama principal y preparar Pull Requests más claros.
Sin embargo, también puede pasar que una rama se cree desde una base incorrecta. Por ejemplo, en lugar de crear una nueva rama desde main, se crea desde otra rama de desarrollo que todavía no está lista para integrarse. Cuando esto ocurre, el Pull Request puede mostrar muchos commits adicionales que no pertenecen realmente al cambio que queremos subir.
El problema
Supongamos que tenemos una rama principal:
mainTambién existe una rama de desarrollo para una integración grande:
feature/integracion-apiDespués se crea una nueva rama para una funcionalidad más pequeña, por ejemplo el registro del costo de envío:
feature/integracion-enviosEl detalle es que esta última rama fue creada accidentalmente desde feature/integracion-api y no desde main. Entonces, al intentar crear un Pull Request hacia main, GitHub muestra que se van a aplicar muchos commits adicionales.
En ese punto la señal de alerta es clara: si la funcionalidad era pequeña, pero el Pull Request muestra demasiados commits o archivos que no corresponden, no conviene hacer el merge todavía.
Por qué no era buena idea hacer el merge directo
Si se hacía el merge directo de feature/integracion-envios hacia main, también se podían integrar cambios incompletos de la rama feature/integracion-api. Esto habría mezclado funcionalidades distintas y pudo provocar errores en producción o en el ambiente de pruebas.
El objetivo era integrar únicamente los commits relacionados con el registro del costo de envío, sin arrastrar el trabajo de otra rama.
La solución: crear una rama limpia desde main
La solución fue crear una nueva rama partiendo correctamente desde main y después aplicar únicamente los commits necesarios usando git cherry-pick.
El comando git cherry-pick permite tomar uno o varios commits específicos de otra rama y aplicarlos sobre la rama actual. Esto resulta útil cuando queremos rescatar cambios puntuales sin mezclar todo el historial de la rama original.
1. Actualizar la información del repositorio
Primero se actualiza la información del repositorio remoto:
git fetch originEste comando descarga las referencias más recientes de las ramas remotas, sin modificar directamente el código de la rama actual.
2. Cambiar a main y actualizarla
Después se cambia a la rama principal y se actualiza con los últimos cambios disponibles:
git checkout main
git pull origin mainEsto asegura que la nueva rama limpia se cree desde la versión más reciente de main.
3. Crear una nueva rama limpia
Con main actualizada, se crea una nueva rama limpia para la funcionalidad:
git checkout -b feature/integracion-envios-cleanEsta nueva rama ya no tendrá como base la rama de integración grande, sino directamente main.
4. Identificar los commits correctos
El siguiente paso es identificar los commits que realmente corresponden a la funcionalidad de envíos.
git log --oneline origin/feature/integracion-api..origin/feature/integracion-enviosEste comando ayuda a visualizar los commits que existen en la rama de envíos, pero que no forman parte de la rama base desde la que fue creada.
El resultado puede ser algo como:
abc1234 Agrega campo de costo de envío al pedido
def5678 Ajusta cálculo total incluyendo envíoEn este ejemplo, esos dos commits serían los únicos que realmente se necesitan aplicar en la rama limpia.
5. Aplicar los commits con cherry-pick
Una vez identificados los commits correctos, se aplican sobre la rama limpia:
git cherry-pick abc1234 def5678Con esto, Git toma los cambios introducidos por esos commits y los aplica sobre la rama actual, generando nuevos commits con esos mismos cambios.
Si durante el proceso aparecen conflictos, se deben resolver manualmente, agregar los archivos corregidos y continuar el cherry-pick:
git add .
git cherry-pick --continueSi fuera necesario cancelar el proceso, se puede usar:
git cherry-pick --abort6. Revisar los cambios antes de subir la rama
Antes de subir la nueva rama, se revisa el estado del repositorio:
git statusTambién es recomendable revisar qué archivos quedaron modificados:
git diff --name-only main...feature/integracion-envios-cleanLa idea es confirmar que la rama limpia solo contiene archivos relacionados con la funcionalidad que se quiere integrar.
7. Subir la rama limpia al repositorio remoto
Una vez revisado todo, se sube la nueva rama a GitHub:
git push -u origin feature/integracion-envios-cleanDespués de esto, ya es posible crear un nuevo Pull Request desde la rama limpia hacia main.
8. Crear el Pull Request correcto
En GitHub, el nuevo Pull Request debe quedar configurado de esta forma:
base: main
compare: feature/integracion-envios-cleanAhora el Pull Request mostrará únicamente los commits necesarios y los archivos relacionados con el registro del costo de envío.
Esto permite hacer una revisión más clara, evitar mezclar funcionalidades y mantener la rama main limpia.
Flujo completo de comandos
El flujo completo quedaría de la siguiente manera:
git fetch origin
git checkout main
git pull origin main
git checkout -b feature/integracion-envios-clean
git log --oneline origin/feature/integracion-api..origin/feature/integracion-envios
git cherry-pick abc1234 def5678
git status
git diff --name-only main...feature/integracion-envios-clean
git push -u origin feature/integracion-envios-cleanBuenas prácticas para evitar este problema
Antes de empezar una nueva funcionalidad, es recomendable seguir este flujo:
git checkout main
git pull origin main
git checkout -b feature/nueva-funcionalidadTambién conviene revisar la rama actual antes de crear una nueva:
git branch --show-currentCon este pequeño hábito se evitan muchos problemas al momento de crear Pull Requests.
Conclusión
Cuando una rama se crea desde la base incorrecta, no siempre es necesario rehacer todo el trabajo. Si los cambios están organizados en commits claros, podemos crear una rama limpia desde main y aplicar únicamente los commits necesarios con git cherry-pick.
En este caso, la solución fue evitar el merge directo, crear una nueva rama limpia, aplicar los commits correctos y generar un Pull Request más claro y seguro. Esto permitió integrar la funcionalidad sin arrastrar cambios de otra rama que todavía no estaba lista.
Este tipo de situaciones son comunes en proyectos reales, y aprender a resolverlas correctamente ayuda a mantener un historial limpio, reducir errores y mejorar el flujo de trabajo en equipo.
Deja un comentario