Experto en Flujo de Trabajo Git - Prompt de Sistema

# Git Workflow Expert - Análisis y Plan de Implementación ## Contexto - **Estructura del repositorio**: Repositorio Git estándar con ramas `main` y `develop` actualmente, sin protección de ramas configurada - **Modelo de ramificación actual**: Flujo simple sin convenciones establecidas - **Tamaño del equipo**: 5-10 desarrolladores trabajando simultáneamente - **Patrones de colaboración**: Pull requests directos a `main`, sin revisión obligatoria - **Pipeline CI/CD**: Integración continua básica con ejecución de tests en cada push ## Plan de Workflow - [ ] **GIT-PLAN-1.1 [Estrategia de Ramificación]**: - **Modelo**: Git Flow simplificado (feature, develop, release, hotfix, main) - **Ramas**: - Largo plazo: `main` (producción), `develop` (integración) - Efímeras: `feature/*`, `bugfix/*`, `hotfix/*`, `release/*` - **Protección**: - `main`: Requiere revisión de al menos 1 aprobador, checks de CI obligatorios, sin force-push - `develop`: Requiere checks de CI, sin force-push directo - **Naming**: `feature/descripcion-corta`, `bugfix/descripcion-corta`, `hotfix/descripcion-corta`, `release/vX.Y.Z` - [ ] **GIT-PLAN-1.2 [Convención de Commits]**: - **Formato**: Conventional Commits (`feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, `test:`) - **Validación**: Hook `commit-msg` con commitlint - **Alcance**: Opcional pero recomendado para módulos específicos - **Ejemplo**: `feat(auth): implementar autenticación JWT` - [ ] **GIT-PLAN-1.3 [Política de Merge]**: - **Estrategia**: `--no-ff` en ramas protegidas para preservar contexto - **Squash**: Solo en ramas de feature antes del merge a `develop` - **Rebase**: Permitido solo en ramas locales no compartidas - **Revert**: Preferido sobre reset en ramas compartidas ## Items de Workflow - [ ] **GIT-ITEM-1.1 [Setup de Husky]**: - **Hook**: Instalación de Husky v9 para gestión de hooks - **Propósito**: Ejecutar hooks de forma consistente en todos los entornos - **Herramienta**: Husky + lint-staged + commitlint - **Fallback**: Si falla la instalación, usar scripts manuales en `.git/hooks/` - [ ] **GIT-ITEM-1.2 [Hook pre-commit]**: - **Hook**: `pre-commit` - **Propósito**: Ejecutar linting y formateo solo en archivos staged - **Herramienta**: lint-staged con ESLint y Prettier - **Fallback**: Bloquear el commit si hay errores de linting - [ ] **GIT-ITEM-1.3 [Hook commit-msg]**: - **Hook**: `commit-msg` - **Propósito**: Validar formato de mensajes según Conventional Commits - **Herramienta**: commitlint con configuración `@commitlint/config-conventional` - **Fallback**: Rechazar el commit con mensaje de error claro - [ ] **GIT-ITEM-1.4 [Hook pre-push]**: - **Hook**: `pre-push` - **Propósito**: Ejecutar suite de tests antes de push - **Herramienta**: Script npm (`npm test`) - **Fallback**: Bloquear push si los tests fallan - [ ] **GIT-ITEM-1.5 [Protección de Ramas]**: - **Hook**: Configuración de branch protection en GitHub/GitLab - **Propósito**: Prevenir merges no revisados y force-push en ramas críticas - **Herramienta**: Configuración nativa de la plataforma - **Fallback**: Documentar procedimiento manual de revisión ## Cambios de Código Propuestos ### package.json (agregar scripts y dependencias) ```json { "scripts": { "lint": "eslint . --ext .js,.jsx,.ts,.tsx", "format": "prettier --write .", "test": "jest", "prepare": "husky" }, "devDependencies": { "@commitlint/cli": "^18.0.0", "@commitlint/config-conventional": "^18.0.0", "husky": "^9.0.0", "lint-staged": "^15.0.0" }, "lint-staged": { "*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"], "*.{json,css,md}": ["prettier --write"] } } ``` ### .husky/pre-commit ```bash #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" npx lint-staged ``` ### .husky/commit-msg ```bash #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" npx --no -- commitlint --edit "$1" ``` ### .husky/pre-push ```bash #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" npm test ``` ### commitlint.config.js ```javascript module.exports = { extends: ['@commitlint/config-conventional'], rules: { 'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']], 'subject-case': [2, 'never', ['sentence-case', 'start-case', 'pascal-case', 'upper-case']], 'body-max-line-length': [0], 'footer-max-line-length': [0] } }; ``` ### .gitignore (agregar) ```gitignore # Dependencias node_modules/ # Build dist/ build/ # Tests coverage/ # Logs *.log npm-debug.log* # Editor .vscode/ .idea/ # OS .DS_Store Thumbs.db # Env .env .env.local .env.*.local ``` ## Comandos ### Instalación inicial ```bash # Instalar dependencias npm install --save-dev husky lint-staged @commitlint/cli @commitlint/config-conventional # Inicializar Husky npx husky init # Crear hooks echo "npx lint-staged" > .husky/pre-commit echo "npx --no -- commitlint --edit \"\$1\"" > .husky/commit-msg echo "npm test" > .husky/pre-push # Hacer ejecutables los hooks chmod +x .husky/pre-commit .husky/commit-msg .husky/pre-push # Configurar protección de ramas (GitHub CLI) gh api repos/{owner}/{repo}/branches/main/protection \ --method PUT \ --field required_status_checks='{"strict":true,"contexts":["continuous-integration"]}' \ --field enforce_admins=true \ --field required_pull_request_reviews='{"required_approving_review_count":1}' ``` ### Verificación ```bash # Verificar hooks instalados ls -la .husky/ # Probar commit message válido git commit -m "feat(auth): implementar login con JWT" # Probar commit message inválido (debe fallar) git commit -m "arreglar bug" # Ejecutar lint-staged manualmente npx lint-staged # Verificar configuración de protección gh api repos/{owner}/{repo}/branches/main/protection ``` ## Checklist de Aseguramiento de Calidad - [ ] Todos los comandos propuestos son seguros e incluyen instrucciones de rollback - [ ] Las reglas de protección de ramas cubren `main` y `develop` - [ ] Los hooks de Git son compatibles multiplataforma (Windows, macOS, Linux) - [ ] Las convenciones de mensajes de commit están documentadas y son aplicables - [ ] Existen procedimientos de recuperación para cada operación destructiva - [ ] El workflow se integra con el pipeline CI/CD existente - [ ] Existe un plan de comunicación para cambios en el workflow ## Procedimientos de Recuperación - [ ] **GIT-REC-1.1 [Recuperación de commits perdidos]**: - Comando: `git reflog` para encontrar commits perdidos - Procedimiento: Crear rama de respaldo desde el reflog antes de cualquier operación destructiva - [ ] **GIT-REC-1.2 [Abortar rebase fallido]**: - Comando: `git rebase --abort` - Procedimiento: Documentar cuándo usar abort vs continue vs skip - [ ] **GIT-REC-1.3 [Revertir cambios en producción]**: - Comando: `git revert <commit-hash>` - Procedimiento: Preferir revert sobre reset en ramas compartidas ## Plan de Comunicación al Equipo - [ ] **GIT-COMM-1.1 [Documentación]**: - Crear `CONTRIBUTING.md` con todas las convenciones - Documentar el flujo de trabajo completo en la wiki del proyecto - [ ] **GIT-COMM-1.2 [Sesión de entrenamiento]**: - Programar sesión de 30 minutos para explicar el nuevo workflow - Demostrar ejemplos de commits válidos e inválidos - [ ] **GIT-COMM-1.3 [Notificación de cambios]**: - Anunciar cambios en el canal del equipo - Explicar el impacto en el flujo diario de trabajo