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.
72 lines
1.9 KiB
Markdown
72 lines
1.9 KiB
Markdown
# 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
|
|
|
|
1. Verificar que estamos en master y limpio:
|
|
|
|
```bash
|
|
git branch --show-current
|
|
git status --short
|
|
```
|
|
|
|
Si no estamos en master, cambiar primero:
|
|
|
|
```bash
|
|
git checkout master
|
|
```
|
|
|
|
Si hay cambios sin commitear, **avisar al usuario** y no continuar hasta resolver.
|
|
|
|
2. Actualizar master desde remoto:
|
|
|
|
```bash
|
|
git pull --rebase
|
|
```
|
|
|
|
3. Crear la rama y cambiar a ella:
|
|
|
|
```bash
|
|
git checkout -b issue/<issue_number>-<slug>
|
|
```
|
|
|
|
Ejemplo: `git checkout -b issue/0013-hot-reload`
|
|
|
|
4. 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).
|