Git es la herramienta de control de versiones más usada del mundo, pero la mayoría de los desarrolladores solo usa una fracción de sus capacidades. Rebase, cherry-pick y las estrategias de merge son funcionalidades avanzadas que, bien aplicadas, producen un historial de commits limpio, facilitan el code review y reducen los conflictos en equipos con múltiples desarrolladores trabajando en paralelo.
Merge vs Rebase: la discusión que divide equipos
La diferencia entre merge y rebase no es solo técnica: es una decisión sobre qué historia quiere contar el repositorio. Git merge preserva el historial real, incluyendo los commits de cada rama y el momento exacto en que se integraron. Git rebase reescribe el historial, haciendo que parecer que los commits de una rama se hicieron sobre el HEAD actual del branch destino.
El merge produce un historial fiel pero ruidoso: muchos commits de merge que dificultan seguir la evolución del código. El rebase produce un historial lineal y legible pero ‘miente’ sobre cuándo ocurrieron los cambios. Ninguno es objetivamente mejor: la elección depende de los valores del equipo y del tipo de proyecto.
Rebase interactivo: la herramienta más poderosa de Git
El rebase interactivo (git rebase -i) permite reordenar, combinar, editar o eliminar commits antes de integrarlos. Es la herramienta ideal para limpiar el historial de una rama antes de abrir un Pull Request: los commits ‘WIP’, ‘fix typo’ y ‘trying something’ se pueden combinar en commits atómicos con mensajes descriptivos.
pick: mantener el commit tal como estáreword: mantener los cambios pero editar el mensaje del commitsquash: combinar este commit con el anteriorfixup: como squash pero descarta el mensaje del commitdrop: eliminar el commit completamenteedit: parar en este commit para modificar los cambios
Cherry-pick: aplicar commits específicos
Cherry-pick permite aplicar el cambio de un commit específico en otro branch, sin traerse toda la rama. Es útil para hotfixes críticos que hay que aplicar en múltiples versiones del software, para rescatar un cambio útil de una rama que no está lista para integrar o para construir una rama de release con un subset de features.
El riesgo del cherry-pick es crear divergencias entre branches que complican la integración futura. Si se usa regularmente como sustituto de una estrategia de branching bien diseñada, acumula deuda técnica en el historial del repositorio.
Estrategias de branching para equipos
Gitflow es el modelo clásico: branches main, develop, feature/*, release/* y hotfix/*. Funciona bien para proyectos con releases en ciclos definidos. GitHub Flow es más simple: un branch main y branches de feature que se integran directamente con Pull Requests. Ideal para equipos con deployment continuo.
Trunk-Based Development es el modelo más moderno: todos trabajan directamente sobre main con feature flags para código no listo para producción. Requiere disciplina y buena cobertura de tests, pero elimina el overhead de gestionar múltiples branches de larga duración.
En Octopus Agencia Digital trabajamos con GitHub Flow en proyectos de desarrollo web. Si tu equipo necesita establecer o mejorar sus prácticas de control de versiones, hablá con nosotros.
