Feature Branch en Git: qué es, cómo crear y trabajar con ramas

Qué es un Feature Branch en Git

Feature Branch (rama de funcionalidad) es una rama temporal en Git creada a partir de develop para desarrollar una funcionalidad específica. A diferencia de las ramas de larga duración main y develop, las ramas feature existen por un tiempo limitado — desde unas horas hasta unas semanas.

El objetivo principal de feature branch es aislar los cambios relacionados con una tarea del resto del código. El desarrollador puede experimentar, hacer múltiples commits e incluso romper el código en su propia rama sin afectar el trabajo de otros miembros del equipo.

Después de completar el desarrollo, la rama feature se fusiona de vuelta a develop a través de un Pull Request con revisión de código obligatoria. Después de la fusión, la rama generalmente se elimina para mantener el repositorio limpio.

Según Vincent Driessen, 2010, el modelo Git Flow con ramas feature se convirtió en un estándar de la industria gracias a la clara separación de responsabilidades entre diferentes tipos de ramas.

Flujo de trabajo con Feature Branch

El flujo de trabajo con feature branch consta de una secuencia de pasos que el desarrollador realiza para cada nueva funcionalidad. Este proceso minimiza los conflictos de fusión y garantiza el control de calidad del código.

1. Creación de la rama a partir del último commit de develop. El desarrollador se cambia a develop, lo actualiza y crea una nueva rama feature.
2. Desarrollo y commits en la rama feature. El desarrollador realiza cambios, hace commits con descripciones claras y envía periódicamente la rama al repositorio remoto.
3. Sincronización con develop — durante el desarrollo, la rama principal puede avanzar. El desarrollador realiza un rebase o merge de develop en su rama feature.
4. Creación de un Pull Request — cuando la funcionalidad está lista, el desarrollador abre un PR para revisión de código. El equipo revisa el código y deja comentarios.
5. Fusión y eliminación — después de la aprobación del PR, la rama se fusiona en develop y se elimina tanto local como remotamente.

La sincronización periódica con develop es críticamente importante. Cuanto más tiempo viva una rama feature sin fusionar cambios de develop, mayor será la probabilidad de conflictos en la fusión final.

Frecuencia de sincronización de la rama feature

Reglas de nomenclatura de ramas feature

La nomenclatura de ramas es una parte importante de la disciplina del equipo. Un estándar de nombres uniforme permite identificar rápidamente en qué tarea se está trabajando y quién la está realizando.

• feature/nombre — el prefijo feature/ se usa en Git Flow clásico. Ejemplo: feature/added-auth-module.
• feature/JIRA-123-descripción — vinculación al número de tarea en el sistema de seguimiento. Ejemplo: feature/PROJ-42-add-login.
• feature/tipo/nombre — formato extendido con indicación del tipo de tarea. Ejemplo: feature/feat/analytics-dashboard.

El uso del ID de tarea de JIRA, Trello u otro sistema es una mejor práctica. Vincula automáticamente el código con la tarea y simplifica la búsqueda de ramas a través de git log.

Proceso de Pull Request

Pull Request (o Merge Request en GitLab) es una solicitud para fusionar la rama feature en develop. Un PR no es solo una operación técnica, sino un proceso de revisión de código en equipo que mejora la calidad del código y difunde el conocimiento dentro del equipo.

Un buen PR contiene un título con una breve descripción de la tarea, un enlace al ticket y una descripción de los cambios. El desarrollador debe indicar qué se hizo exactamente, qué archivos se modificaron y si existen riesgos potenciales para otras partes del proyecto.

El equipo revisa el código en el PR, deja comentarios, solicita cambios (change requests) y aprueba la fusión (approve). Después de la aprobación, se realiza un merge o squash merge.

El tiempo promedio de revisión de un PR en el desarrollo móvil es de 4 a 24 horas. La biblioteca Danger automatiza parte de las verificaciones, ejecutando linters y pruebas directamente en el PR.

Recomendaciones para crear un buen PR

• Tamaño — no más de 300-400 líneas de cambios. Los PR grandes son difíciles de revisar y la calidad de la revisión disminuye.
• Un PR — una tarea — evite mezclar cambios no relacionados en una misma solicitud.
• Capturas de pantalla — para cambios de UI, adjunte capturas de antes y después.
• Pruebas — para nueva funcionalidad, escriba pruebas unitarias e inclúyalas en el PR.

Estrategias de fusión de ramas feature

Después de la aprobación del PR, la rama feature puede fusionarse en develop de diferentes maneras. La elección de la estrategia de fusión afecta el historial de commits y la posibilidad de revertir cambios.

• Merge commit — crea un commit de fusión, conservando todo el historial de commits de la rama feature. El historial permanece completo, pero el gráfico de ramificaciones se vuelve más complejo.
• Squash merge — combina todos los commits de la rama feature en uno solo y lo agrega sobre develop. El historial se vuelve más limpio, pero se pierde información sobre los commits intermedios.
• Rebase and merge — reescribe los commits de la rama feature sobre el último commit de develop y fusiona sin un commit adicional. El historial permanece lineal.

Para proyectos móviles con lanzamientos frecuentes, el squash merge es el más utilizado: proporciona un historial limpio en develop, mientras que los detalles del desarrollo permanecen en la descripción del PR y en la tarea del tracker.

Errores típicos al trabajar con Feature Branch

Incluso los desarrolladores experimentados cometen errores al trabajar con ramas feature. Conocer los problemas típicos ayuda a evitar la pérdida de tiempo y datos.

• Vida demasiado larga de la rama — una rama feature vive más de 2-3 semanas sin sincronización con develop, lo que provoca conflictos de fusión masivos.
• Commits con descripciones poco claras — mensajes como “fix” o “update” no permiten entender qué se cambió y por qué.
• Mezcla de tareas — en una misma rama feature se desarrollan dos funcionalidades no relacionadas, lo que hace imposible la reversión selectiva.
• Falta de sincronización — el desarrollador no hace git fetch ni actualiza develop, lo que genera conflictos en la fusión final.

La mejor manera de evitar estos problemas es acordar las reglas de trabajo al inicio del proyecto y usar verificaciones automatizadas en el pipeline de CI/CD.

Ejemplos de comandos para trabajar con Feature Branch

Consideremos un escenario práctico: un desarrollador comienza una nueva función de autenticación en una aplicación móvil. Crea una rama feature, trabaja en el código y completa la tarea con un Pull Request.

# Actualizar develop y crear rama feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Trabajo en la funcionalidad: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# Enviar rama feature al servidor remoto
git push origin feature/add-login-screen

# Sincronización con develop (rebase)
git fetch origin develop
git rebase origin/develop

# Después de aprobar PR: actualizar develop local y eliminar la rama
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

El comando git branch -d elimina la rama solo después de que sus cambios se hayan fusionado completamente. Si la rama no está fusionada, Git sugerirá usar git branch -D para la eliminación forzada — use esta bandera con precaución.

Automatización de verificaciones en la rama feature

El pipeline de CI/CD debe ejecutarse para cada rama feature antes de crear un PR. Esto permite detectar problemas en una etapa temprana, antes de que el código llegue a la revisión de otros desarrolladores.

# GitHub Actions para verificar la rama feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

El pipeline verifica que el código compile, las pruebas pasen y el estilo del código cumpla con los estándares del equipo. Solo después de superar todas las verificaciones se puede crear un Pull Request.