# 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).