Git sin dramas: cómo trabajamos con ramas y Pull Requests

Cuando un solo desarrollador trabaja en un proyecto, Git es casi un detalle: guardas, subes, listo. La cosa cambia cuando varias personas tocan el mismo código a la vez. Sin reglas claras, alguien sobrescribe el trabajo de otro, el historial se vuelve un nudo y un viernes por la tarde aparece el temido “¿quién borró mis commits?”.

La buena noticia es que evitar todo eso no requiere comandos mágicos, sino un flujo de trabajo claro y unos cuantos hábitos. En este artículo explicamos el que usamos en la mayoría de nuestros proyectos, de forma que cualquiera en un equipo pueda adoptarlo.

La regla que lo sostiene todo: la rama principal es sagrada. Siempre debe estar estable, lista para desplegar, y nadie le reescribe el historial.

No hay una sola forma “correcta”

Antes de entrar en detalle, conviene aclarar algo: no existe un único flujo de Git que sirva para todo. Con los años la comunidad fue puliendo varias estrategias, y cada una nace de un tipo de proyecto distinto:

• GitFlow — el más estructurado, con ramas dedicadas para desarrollo, releases y hotfixes. Brilla en software con versiones formales y ciclos de release largos (piensa en una app de escritorio que saca la versión 2.3). A cambio, es pesado para el día a día.
• GitHub Flow — mucho más ligero: una sola rama principal siempre desplegable, y una rama corta por cada tarea que entra por Pull Request. Ideal para productos web que se despliegan seguido.
• Trunk-based — todos integran a una sola rama (el “tronco”) varias veces al día, con ramas que viven horas, no días. Es lo que usan equipos grandes con integración continua muy madura.

No son recetas rígidas ni hay que casarse con una. En Nextik elegimos la que mejor le quede a cada proyecto: su tamaño, qué tan seguido se despliega y cuánta gente toca el código. Dicho eso, para la mayoría de lo que hacemos —productos web que se actualizan de forma continua— el punto dulce es GitHub Flow, y es el que describimos a continuación.

El modelo: una rama por tarea, un Pull Request a main

No usamos ramas intermedias ni flujos complicados. El modelo cabe en una frase: cada tarea vive en su propia rama corta, sale de main y vuelve a main por un Pull Request revisado.

• main es la única rama de larga vida. Siempre estable.
• Cada feature, bug o ajuste tiene su propia rama, que nace de main y muere cuando se mergea.
• Las ramas son desechables: se crean, se revisan, se integran y se borran. No se acumulan.

Esto mantiene el trabajo de cada quien aislado hasta que está listo y revisado. Nadie rompe main, porque a main solo se entra por la puerta del Pull Request.

El ciclo de una tarea

En la práctica, el día a día se ve así. Primero, partir siempre de una rama principal actualizada:

git switch main
git pull
git switch -c feat/login-con-google

Le ponemos a la rama un nombre que diga de qué se trata, con un prefijo según el tipo de trabajo: feat/ para algo nuevo, fix/ para una corrección, chore/ para mantenimiento, refactor/ para reestructurar sin cambiar comportamiento. Así, de un vistazo a la lista de ramas se entiende qué está pasando.

Luego se trabaja en commits pequeños y con sentido — cada uno hace una sola cosa y no rompe el proyecto:

git add -p
git commit -m "Agrega botón de login con Google"
git push -u origin feat/login-con-google

Con la rama subida, se abre el Pull Request hacia main: un buen título, una descripción de qué cambia y por qué, y a esperar la revisión del equipo. El PR es donde se discute, se sugiere y se mejora antes de que el código toque la rama principal.

Y cuando se aprueba, la limpieza es casi automática

Al hacer merge del Pull Request, la rama remota se borra sola — lo tenemos configurado así, y es una pequeña decisión que evita acumular decenas de ramas muertas en el repositorio. En tu propia máquina solo queda volver a la rama principal y actualizar:

git switch main
git pull

Esa rama local que ya se mergeó puedes borrarla sin miedo (git branch -d nombre-rama), o dejar que git fetch --prune limpie las referencias a ramas remotas que ya no existen. Cero ceremonia.

Un apunte: git switch en vez de git checkout

Quizá en tutoriales viejos viste git checkout para cambiar de rama. Nosotros preferimos git switch, y hay una buena razón: checkout hace demasiadas cosas distintas según los argumentos, y una de ellas es peligrosa.

git checkout main          # cambia de rama
git checkout archivo.ts    # ⚠️ descarta tus cambios en ese archivo, sin avisar

Es una trampa clásica: querías cambiar de rama, te equivocas de argumento y borras trabajo no guardado. Por eso Git dividió ese comando en dos más enfocados y seguros: git switch para moverte entre ramas y git restore para descartar o recuperar archivos. switch no puede borrarte nada por accidente, y eso ya es razón suficiente.

Mantener tu rama al día: rebase

Mientras trabajas en tu rama, el equipo sigue mergeando otros PRs a main. Tu rama se “queda atrás” respecto a la versión más reciente. Para ponerla al día tienes dos caminos, y nosotros preferimos rebase porque deja un historial lineal y fácil de leer.

rebase toma tus commits y los vuelve a aplicar encima del main actualizado, como si los hubieras hecho hoy:

git fetch origin
git rebase origin/main

Comparado con un merge —que trae los cambios pero deja un “commit de merge” extra y bifurcaciones en el historial—, el rebase mantiene todo como una sola fila ordenada de commits. Más fácil de leer hoy, y mucho más fácil de auditar dentro de seis meses.

Regla importante: solo se hace rebase de tu propia rama, la que nadie más está usando. Reescribir el historial de una rama compartida le rompe el repositorio a quien ya la había descargado.

El force push: aquí es donde casi todos se queman

Después de un rebase, tu rama local tiene un historial distinto al que ya habías subido. Git rechazará un push normal, y la tentación es resolver con git push --force. Ese es exactamente el hábito que causa los peores accidentes.

El problema de --force a secas es que sobrescribe lo que haya en el servidor sin preguntar. Si un compañero subió commits a esa rama que tú no tienes, los borras. Sin red, sin aviso.

La alternativa segura es:

git push --force-with-lease

--force-with-lease primero verifica: “¿el remoto sigue como yo lo dejé?”. Si alguien subió algo nuevo, aborta el push y te avisa, en lugar de pisar el trabajo ajeno. Hace lo mismo que --force, pero con un seguro puesto.

Las reglas que seguimos son simples:

• Nunca se hace force push (de ningún tipo) a la rama principal.
• Sobre tu propia rama, después de un rebase, --force-with-lease está perfectamente bien.
• Si una rama la comparten varias personas, se avisa antes de reescribir su historial.
• El force push no es un atajo para resolver conflictos. Si lo usas para “salir del paso”, algo más arriba en el flujo se rompió.

cherry-pick: traer un commit suelto

A veces no quieres una rama entera, solo un commit específico. Por ejemplo: hay un arreglo urgente metido dentro de una rama a medio terminar, y lo necesitas en producción ya. cherry-pick copia ese commit a donde lo necesites:

git switch -c fix/hotfix-urgente main
git cherry-pick a1b2c3d

También salva el día cuando te equivocas de rama y haces un commit donde no iba: lo “cosechas” hacia la rama correcta y lo quitas de donde no debía estar. Es una herramienta de precisión — úsala para cambios puntuales, no para mover ramas completas.

La red de seguridad: git reflog

Si hay un solo comando que da tranquilidad para experimentar, es este. En Git casi nada se pierde de verdad: durante unas semanas, cada movimiento de tus ramas queda registrado. Si crees que un rebase o un reset “borró” un commit, git reflog te muestra dónde estaba y puedes recuperarlo. Saber que existe esta red cambia por completo la relación con Git: dejas de tenerle miedo y empiezas a usar bien sus herramientas.

En resumen

Un buen flujo de Git no se trata de memorizar comandos, sino de proteger el trabajo del equipo:

• Una rama por tarea, siempre desde un main actualizado.
• Todo entra a main por un Pull Request revisado.
• rebase para mantener el historial limpio y lineal.
• --force-with-lease, nunca --force a secas, y jamás sobre main.
• cherry-pick para cambios quirúrgicos y reflog como red de seguridad.

Son cinco hábitos, no cincuenta. Adoptarlos es la diferencia entre un repositorio que da gusto trabajar y uno que da miedo tocar — y, sobre todo, entre un equipo que avanza junto y uno que se pisa entre sí.