egutierrez
abfd04420f
Añade documentación completa del flujo trunk-based development a todos los archivos de reglas y comandos del proyecto: - CLAUDE.md: sección completa de TBD con flujo, commits, ramas y feature flags - git-branch.md: sección de features multi-issue y reglas de commits - git-push.md: reglas críticas de commits (no WIP, no squash, no rebase -i) - create_issue.md: guía de desglose en sub-issues con feature flags - fix_issue.md: cuándo usar/no usar feature flags, flujo multi-issue - index.md: resumen expandido del flujo TBD con commits y flags Impacto: todas las reglas ahora documentan consistentemente el flujo de desarrollo, convenciones de commits y uso de feature flags.
1.9 KiB
1.9 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
- No rebase interactivo: si los commits son limpios desde el inicio, no reescribir historia
- No commits WIP: cada commit en la rama debe ser atomico y con mensaje real (ver convencion en
/git-push)
Features multi-issue
Para features que no caben en una sola rama, usar sub-issues con sufijo letra:
issue/0015a-telegram-types
issue/0015b-telegram-client
issue/0015c-telegram-listener
issue/0015d-telegram-enable
Cada sub-rama sigue el mismo flujo: crear → implementar → merge --no-ff → delete.
El codigo parcial se protege con feature flags en dev/feature_flags.json (no con commits WIP).