egutierrez
9a77ef59e8
Se añaden las reglas y commands para el flujo trunk-based completo: - fix_issue.md: guía para implementar issues (rama → tests → merge) - git-branch.md: command para crear ramas issue/<NNNN>-<slug> - git-push.md: actualizado con flujo de ramas, tests obligatorios y feature flags - create_issue.md: ajustado formato de numeración a 4 dígitos - index.md: añadida sección de flujo de desarrollo y regla fix_issue - CLAUDE.md: referencia a la nueva regla fix_issue - feature_flags.json: archivo base para flags de despliegue por fases Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1.3 KiB
1.3 KiB
Command: git branch (TBD)
Crea una rama de trabajo para un issue. Nunca trabajar directamente en master.
Inputs
Se necesita el numero del issue y el slug. Si no se proporcionan, preguntar.
issue_number: numero de 4 digitos (e.g.0020)slug: nombre corto separado por guiones (e.g.hot-reload)
Flujo obligatorio
- Verificar que estamos en master y limpio:
git branch --show-current
git status --short
Si no estamos en master, cambiar primero:
git checkout master
Si hay cambios sin commitear, avisar al usuario y no continuar hasta resolver.
- Actualizar master desde remoto:
git pull --rebase
- Crear la rama y cambiar a ella:
git checkout -b issue/<issue_number>-<slug>
Ejemplo: git checkout -b issue/0013-hot-reload
- Confirmar al usuario:
Rama `issue/<issue_number>-<slug>` creada desde master actualizado.
Puedes empezar a trabajar. Cuando termines, usa `/git-push` para integrar a master.
Convenciones
- Formato de rama:
issue/<NNNN>-<slug>(siempre 4 digitos) - Ramas cortas: idealmente horas, no dias
- Una rama por issue: no mezclar issues en la misma rama
- Nunca pushear la rama al remoto: el push se hace desde master despues del merge (a menos que se necesite un PR de un agente)