Skip to main content

8. Estrategia de Branching

Esta sección define la estrategia de ramificación (branching) utilizada por el equipo de desarrollo para mantener un flujo de trabajo limpio, organizado y colaborativo sobre los repositorios de código fuente de proyectos Android.

8.1 Objetivos​

  • Facilitar el trabajo colaborativo entre desarrolladores
  • Permitir el desarrollo simultáneo de múltiples funcionalidades
  • Evitar conflictos y errores en el código compartido
  • Mantener una base de código estable para releases

8.2 Convenciones de nombres de ramas​

Tipo de ramaConvenciónUso
MainmainRama principal de producción
DesarrollodevelopRama para integración de funcionalidades
Featurefeature/nombre-descriptivoNueva funcionalidad
Bugfixbugfix/descripcionCorrección de errores menores
Hotfixhotfix/descripcionCorrección urgente en producción
Releaserelease/vX.Y.ZPreparación de versión para producción

8.3 Ejemplos de nombres de ramas​

feature/registro-de-usuario
bugfix/fix-crash-al-iniciar
hotfix/token-expirado-produccion
release/v1.3.0

8.4 Flujo estándar de trabajo​

  1. Crear rama feature/ desde develop
  2. Realizar desarrollo local y commit con convenciones
  3. Push al repositorio remoto
  4. Crear Pull Request contra develop
  5. Revisiones, aprobaciones y pruebas
  6. Merge solo si pasa CI y tiene aprobación técnica

8.5 Protección de ramas​

  • Las ramas main y develop deben estar protegidas:
    • Prohibido el push directo
    • Solo merge permitido vía Pull Request
    • Requiere 2 aprobaciones
    • CI debe pasar exitosamente

8.6 Convenciones de commits (Conventional Commits)​

Todos los commits deben seguir el estándar Conventional Commits para permitir automatización y claridad en el historial.

Formato​

<tipo>[alcance opcional]: descripción corta

Ejemplos​

feat(auth): agregar autenticación biométrica
fix(ui): corregir alineación del botón de guardar
chore: actualizar versión de Kotlin a 1.9.22
test(domain): agregar pruebas unitarias a casos de uso

Este formato es adoptado por empresas como Google, Microsoft, Angular, entre otros.

8.7 Recomendaciones​

✅ Mantener ramas pequeñas y enfocadas
✅ Usar rebase antes de crear un PR para evitar conflictos
✅ Eliminar ramas una vez mergeadas
✅ Documentar en el PR qué cambios se hicieron y por qué
✅ Asociar cada PR a un ticket o historia de usuario

Esta estrategia de branching está basada en buenas prácticas de la industria y permite escalar equipos de desarrollo, integrando fácilmente control de calidad, automatización de pipelines y control de versiones.