1.
Introducción a GitFlow
GitFlow es una metodología de ramificación que define un modelo estricto diseñado para el
lanzamiento de proyectos. Proporciona un marco robusto para gestionar proyectos de gran
escala.
2. Estructura de Ramas en GitFlow
Ramas Principales
main/master: Código en producción
develop: Rama de integración para el desarrollo
Ramas de Soporte
feature/: Para nuevas funcionalidades
release/: Para preparar nuevas versiones
hotfix/: Para correcciones urgentes en producción
3. Convenciones de Nombres de Ramas
# Ramas de funcionalidad
feature/[desarrollador]-[descripcion-corta]
Ejemplo: feature/juan-login-authentication
# Ramas de release
release/v[version]
Ejemplo: release/v1.2.0
# Ramas de hotfix
hotfix/[descripcion-urgente]
Ejemplo: hotfix/critical-security-patch
# Ramas de bugfix (para develop)
bugfix/[descripcion-bug]
Ejemplo: bugfix/fix-user-validation
4. Estándares de Commits (Conventional
Commits)
<tipo>[alcance opcional]: <descripción>
[cuerpo opcional]
[pie opcional]
Tipos de Commit
feat: Nueva funcionalidad
fix: Corrección de errores
docs: Cambios en documentación
style: Formato, espacios, etc.
refactor: Refactorización de código
test: Añadir o modificar tests
chore: Tareas de mantenimiento
Ejemplos
feat(auth): agregar autenticación con JWT
fix(api): corregir validación de email
docs(readme): actualizar instrucciones de instalación
5. Diagrama de Flujo GitFlow
gitGraph
commit id: "Initial"
branch develop
checkout develop
commit id: "Setup"
branch feature/juan-login
checkout feature/juan-login
commit id: "Login UI"
commit id: "Auth logic"
branch feature/maria-dashboard
checkout feature/maria-dashboard
commit id: "Dashboard layout"
commit id: "Charts integration"
checkout develop
merge feature/juan-login
commit id: "Merge login"
branch release/v1.1.0
checkout release/v1.1.0
commit id: "Version bump"
commit id: "Bug fixes"
checkout main
merge release/v1.1.0
commit id: "Release v1.1.0"
checkout develop
merge release/v1.1.0
merge feature/maria-dashboard
checkout main
branch hotfix/security-patch
commit id: "Security fix"
checkout main
merge hotfix/security-patch
checkout develop
merge hotfix/security-patch
6. Asignación de Ramas a Ambientes
Ambiente Rama Propósito
Desarrollo develop Integración continua del equipo
Ambiente Rama Propósito
QA/Testing release/* Pruebas antes de producción
Producción main Código estable en producción
7. Flujo de Trabajo Paso a Paso
Para Desarrolladores
7.1 Iniciar una Nueva Funcionalidad
# 1. Actualizar develop
git checkout develop
git pull origin develop
# 2. Crear rama de funcionalidad
git checkout -b feature/[tu-nombre]-[descripcion]
# 3. Trabajar en la funcionalidad
git add .
git commit -m "feat: descripción del cambio"
# 4. Subir rama al repositorio
git push -u origin feature/[tu-nombre]-[descripcion]
7.2 Finalizar una Funcionalidad
# 1. Actualizar develop
git checkout develop
git pull origin develop
# 2. Volver a tu rama
git checkout feature/[tu-nombre]-[descripcion]
# 3. Rebase con develop
git rebase develop
# 4. Crear Pull Request
# (Usar interfaz de GitHub/GitLab)
7.3 Preparar un Release
# 1. Crear rama de release
git checkout develop
git pull origin develop
git checkout -b release/v[version]
# 2. Actualizar versión y hacer ajustes finales
git commit -m "chore: bump version to v[version]"
git push -u origin release/v[version]
7.4 Finalizar un Release
# 1. Merge a main
git checkout main
git merge --no-ff release/v[version]
git tag -a v[version] -m "Release version [version]"
# 2. Merge a develop
git checkout develop
git merge --no-ff release/v[version]
# 3. Eliminar rama de release
git branch -d release/v[version]
7.5 Hotfix de Emergencia
# 1. Crear rama desde main
git checkout main
git pull origin main
git checkout -b hotfix/[descripcion]
# 2. Hacer el fix
git commit -m "fix: descripción del hotfix"
# 3. Merge a main y develop
git checkout main
git merge --no-ff hotfix/[descripcion]
git tag -a v[version-patch] -m "Hotfix version [version-patch]"
git checkout develop
git merge --no-ff hotfix/[descripcion]
8. Políticas para Pull Requests
8.1 Requisitos Obligatorios
Título descriptivo siguiendo Conventional Commits
Descripción detallada del cambio
Al menos 2 revisores asignados
Tests unitarios actualizados/añadidos
Documentación actualizada si es necesario
Build exitoso en CI/CD
8.2 Template de Pull Request
## Descripción
Breve descripción de los cambios realizados.
## Tipo de cambio
- [ ] Bug fix (cambio que soluciona un problema)
- [ ] Nueva funcionalidad (cambio que añade funcionalidad)
- [ ] Breaking change (cambio que puede afectar funcionalidad existente)
- [ ] Documentación
## Checklist
- [ ] He revisado mi código
- [ ] He añadido tests que prueban mi cambio
- [ ] He actualizado la documentación
- [ ] Mi código sigue las convenciones del proyecto
## Screenshots (si aplica)
Añadir screenshots si hay cambios visuales.
9. Política Interna de Trabajo con Git
9.1 Reglas Generales
1. Nunca hacer push directo a main o develop
2. Siempre trabajar en ramas de funcionalidad
3. Usar Pull Requests para todos los merges
4. Mantener commits pequeños y descriptivos
5. Hacer rebase antes de crear PR
9.2 Responsabilidades por Rol
Desarrolladores
Crear ramas de funcionalidad
Escribir commits descriptivos
Crear Pull Requests
Resolver conflictos de merge
Escribir tests unitarios
Tech Lead/Senior
Revisar Pull Requests
Aprobar merges a develop
Crear y gestionar releases
Supervisar calidad del código
DevOps/Admin
Proteger ramas main y develop
Configurar CI/CD
Gestionar permisos de repositorio
Monitorear métricas de Git
9.3 Revisiones de Código
Mínimo 2 revisores para PRs a develop
Revisión obligatoria del Tech Lead para releases
Revisión inmediata para hotfixes
Feedback constructivo en las revisiones
10. Automatización con Husky y Commitlint
10.1 Configuración de Commitlint
# Instalar dependencias
npm install --save-dev @commitlint/cli @commitlint/config-conventional
# Crear archivo de configuración
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.co
10.2 Configuración de Husky
# Instalar Husky
npm install --save-dev husky
# Activar hooks
npx husky install
# Añadir hook para commit-msg
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'
# Añadir hook para pre-commit (tests)
npx husky add .husky/pre-commit 'npm test'
10.3 Configuración en package.json
{
"scripts": {
"prepare": "husky install",
"test": "jest",
"lint": "eslint src/",
"format": "prettier --write src/"
},
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,ts}": [
"eslint --fix",
"prettier --write",
"git add"
]
}
}
11. Herramientas Recomendadas
11.1 Extensiones de VS Code
GitLens
Git Graph
Conventional Commits
GitKraken (cliente Git visual)
11.2 Configuración de Git Global
# Configuración inicial
git config --global user.name "Tu Nombre"
git config --global user.email "
[email protected]"
git config --global init.defaultBranch main
git config --global pull.rebase true
12. Métricas y Monitoreo
12.1 KPIs a Monitorear
Tiempo promedio de vida de ramas feature
Número de commits por desarrollador
Frecuencia de releases
Tiempo de resolución de hotfixes
Tasa de aprobación de PRs
12.2 Herramientas de Análisis
GitHub Insights
GitLab Analytics
SonarQube para calidad de código
13. Cronograma de Implementación
Semana 1: Preparación
Configurar repositorio principal
Proteger ramas main y develop
Instalar herramientas (Husky, Commitlint)
Crear templates de PR
Semana 2: Capacitación
Sesión de training para el equipo
Práctica con repositorio de prueba
Definir responsabilidades por rol
Semana 3: Implementación
Migrar proyecto actual a GitFlow
Primer release usando la metodología
Ajustar procesos según feedback
Semana 4: Optimización
Revisar métricas iniciales
Automatizar procesos adicionales
Documentar lecciones aprendidas
14. Troubleshooting Común
14.1 Conflictos de Merge
# Resolver conflictos
git status
# Editar archivos conflictivos
git add .
git commit -m "resolve: merge conflicts"
14.2 Revertir Cambios
# Revertir último commit
git revert HEAD
# Revertir commit específico
git revert <commit-hash>
14.3 Limpiar Ramas Locales
# Ver ramas locales
git branch
# Eliminar rama local
git branch -d feature/rama-completada
# Eliminar rama remota
git push origin --delete feature/rama-completada
Documento preparado para: Equipo de Desarrollo
Fecha: [Fecha actual]
Versión: 1.0
Responsable: Tech Lead
Próximos pasos:
1. Revisar documento con el equipo
2. Programar sesión de capacitación
3. Configurar herramientas en repositorio
4. Iniciar implementación gradual
