Guía completa sobre ramas en Git: crear, cambiar y eliminar

Las ramas en Git te permiten trabajar en una funcionalidad, corrección o experimento sin alterar la línea principal de desarrollo. Un buen hábito de ramificación mantiene tus cambios organizados y facilita las revisiones, las pruebas y las reversiones.

Las ramas son punteros ligeros a confirmaciones. Esto significa que crearlas, cambiarlas y eliminarlas es rápido, pero las decisiones que tomes afectan la claridad del historial de tu proyecto.

Qué es una rama en Git

Una rama en Git es un nombre móvil que apunta a una confirmación. Cuando confirmas nuevo trabajo en una rama, Git mueve ese nombre de rama hacia adelante hasta la nueva confirmación.

La mayoría de los proyectos tienen una rama principal como main o master. Los equipos suelen mantener esa rama estable y luego crean ramas de corta duración para trabajos específicos:

git switch -c fix-login-timeout

Esto crea una nueva rama y cambia a ella. Ejemplos más antiguos de Git pueden usar:

git checkout -b fix-login-timeout

Ambos patrones son comunes, pero git switch es más fácil de leer porque se centra solo en el movimiento de ramas.

Los nombres de las ramas deben ser lo suficientemente específicos para explicar el trabajo. feature es demasiado vago. feature/add-health-check-endpoint o fix/nginx-502-upstream-timeout es mucho mejor. Un nombre claro te ayuda a ti y a tus revisores a entender la rama antes de abrir cualquier archivo.

Crear y cambiar de ramas

Antes de crear una rama, comienza desde la base correcta. Para la mayoría de los equipos, esto significa actualizar primero tu rama principal:

git switch main
git pull
git switch -c feature/add-metrics-endpoint

Esto reduce la probabilidad de que tu nueva rama comience desde código desactualizado. No elimina conflictos, pero te da un punto de partida más limpio.

Para listar las ramas locales, ejecuta:

git branch

La rama actual tiene un asterisco junto a ella. Para ver también las ramas remotas, usa:

git branch -a

Para cambiar a una rama existente:

git switch nombre-de-rama

Si la rama solo existe en el remoto, normalmente puedes crear una rama de seguimiento local con:

git switch --track origin/nombre-de-rama

El seguimiento es importante porque conecta tu rama local con su contraparte remota. Una vez configurado el seguimiento, comandos simples como git pull y git push saben qué rama remota usar.

Para un escenario concreto, imagina que necesitas parchear un fallo en una canalización de Jenkins mientras trabajas en una limpieza más grande de imágenes Docker. Pon esos cambios en ramas separadas. El parche urgente puede revisarse y fusionarse rápidamente, mientras que la limpieza más grande puede continuar sin bloquearlo.

Para conceptos básicos relacionados, consulta cómo empezar con repositorios Git.

Mantener las ramas organizadas

Las ramas se vuelven desordenadas cuando permanecen abiertas demasiado tiempo o acumulan cambios no relacionados. La mejor rama suele ser pequeña, enfocada y fácil de revisar.

Usa una rama para un propósito:

• Una rama de corrección de errores debe incluir la corrección y las pruebas relacionadas.
• Una rama de funcionalidad debe incluir la funcionalidad, no refactorizaciones adicionales.
• Una rama de limpieza debe evitar cambios de comportamiento a menos que sean claramente parte de la limpieza.

Antes de enviar, verifica tu trabajo:

git status
git diff --staged

Esto detecta archivos accidentales y ediciones no relacionadas. Es especialmente útil en repositorios de DevOps donde los archivos generados, la configuración local y las plantillas de secretos pueden estar cerca de los archivos fuente reales.

Cuando tu rama necesite los últimos cambios de main, tienes dos opciones comunes:

git merge main

o:

git rebase main

Merge preserva el historial exacto de la rama. Rebase reescribe tus confirmaciones de la rama sobre la base más reciente. Ambos son útiles, pero los equipos deben acordar qué estilo esperan antes de fusionar trabajo compartido. Si no estás seguro, prefiere el flujo de trabajo documentado por tu proyecto.

Eliminar ramas de forma segura

Eliminar ramas antiguas mantiene tu repositorio más fácil de navegar. Después de que una rama se haya fusionado, elimina la copia local con:

git branch -d nombre-de-rama

La opción -d en minúscula es la más segura. Git se niega a eliminar la rama si cree que el trabajo no se ha fusionado.

Si realmente necesitas eliminar una rama local no fusionada, usa:

git branch -D nombre-de-rama

Úsalo con cuidado. Elimina el nombre de la rama incluso si las confirmaciones no están fusionadas. Las confirmaciones pueden ser recuperables por un tiempo a través del reflog, pero no debes tratar eso como una red de seguridad normal.

Para eliminar una rama remota:

git push origin --delete nombre-de-rama

Solo elimina ramas remotas cuando el trabajo esté fusionado, abandonado o claramente sea tuyo. En equipos compartidos, las ramas remotas pueden ser utilizadas por revisiones, vistas previas de despliegue u otros desarrolladores.

Puedes limpiar referencias de seguimiento remoto obsoletas con:

git fetch --prune

Esto elimina referencias locales a ramas remotas que ya no existen en el servidor. No elimina ramas remotas reales.

Cuándo preguntar a un compañero

La creación y el cambio de ramas son operaciones de bajo riesgo. Los momentos riesgosos son eliminar trabajo no fusionado, forzar el envío y reorganizar ramas que otras personas puedan estar usando.

Pregunta antes de forzar el envío a una rama compartida. También pregunta antes de eliminar una rama remota que no creaste. En repositorios con integración continua/despliegue continuo, una rama puede desencadenar compilaciones, vistas previas o reglas de despliegue que no son obvias solo desde Git.

Una buena ramificación se trata principalmente de claridad. Crea una rama desde la base correcta, nómbrala según el trabajo, mantenla enfocada y elimínala cuando ya no sea necesaria. Esos hábitos hacen que Git sea más fácil para ti y más seguro para todo el equipo.