egutierrez
151b02766d
Añadir tipo de rama quick/<slug> a los comandos /git-branch y /git-push para cambios pequeños que no están asociados a un issue existente. Antes, /git-push en master siempre inventaba un número de issue inexistente. Ahora pregunta al usuario si el cambio tiene issue asociado o no. No se modifican los flujos de ramas issue/ ni feature flags.
87 lines
2.3 KiB
Markdown
87 lines
2.3 KiB
Markdown
# Command: git branch (TBD)
|
|
|
|
Crea una rama de trabajo. **Nunca trabajar directamente en master.**
|
|
|
|
Soporta dos tipos de rama:
|
|
- `issue/<NNNN>-<slug>` — para implementar un issue existente de `dev/issues/`
|
|
- `quick/<slug>` — para cambios pequeños sin issue asociado (fixes, config, docs, etc.)
|
|
|
|
## Inputs
|
|
|
|
Preguntar al usuario si el cambio esta asociado a un issue o no.
|
|
|
|
### Si es un issue:
|
|
- `issue_number`: numero de 4 digitos (e.g. `0020`)
|
|
- `slug`: nombre corto separado por guiones (e.g. `hot-reload`)
|
|
|
|
### Si es un cambio rapido (sin issue):
|
|
- `slug`: nombre corto descriptivo separado por guiones (e.g. `fix-typo-readme`)
|
|
|
|
## 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:
|
|
|
|
**Para issues:**
|
|
```bash
|
|
git checkout -b issue/<issue_number>-<slug>
|
|
```
|
|
Ejemplo: `git checkout -b issue/0013-hot-reload`
|
|
|
|
**Para cambios rapidos:**
|
|
```bash
|
|
git checkout -b quick/<slug>
|
|
```
|
|
Ejemplo: `git checkout -b quick/fix-typo-readme`
|
|
|
|
4. Confirmar al usuario:
|
|
|
|
```
|
|
Rama `<nombre-rama>` creada desde master actualizado.
|
|
Puedes empezar a trabajar. Cuando termines, usa `/git-push` para integrar a master.
|
|
```
|
|
|
|
## Convenciones
|
|
|
|
- **Formato de rama issue**: `issue/<NNNN>-<slug>` (siempre 4 digitos)
|
|
- **Formato de rama quick**: `quick/<slug>` (sin numero)
|
|
- **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).
|