# Command: git push (TBD)

Integra cambios a master y publica. Soporta ramas `issue/*` y `quick/*`.

La fase final (`pull --rebase` master + `merge --no-ff` + `git push` + `git branch -d`) la hace `tbd_branch_finish_bash_infra` del registry. Tests y commits **no** los hace la función — los corre el asistente porque dependen del stack.

## Pasos del asistente

### 1. Verificar rama actual y estado

```bash
git branch --show-current
git status --short
```

#### Si estamos en `issue/*` o `quick/*`

Continuar al paso 2.

#### Si estamos en master con cambios pendientes

Crear rama primero:
1. Preguntar si el cambio está asociado a un issue.
2. Si es issue: pedir `<NNNN>` y `<slug>`, llamar `/git-branch issue <NNNN> <slug>`.
3. Si es quick: pedir `<slug>`, llamar `/git-branch quick <slug>`.

**No inventar números de issue.** Solo usar `issue/` si existe en `dev/issues/`.

#### Si estamos en master sin cambios

**STOP**: nada que publicar.

### 2. Revisar cambios y crear commits atómicos

```bash
git status --short
git diff --stat
git diff
```

Crear commits atómicos por bloque lógico. Cada commit agrupa cambios de la misma naturaleza:

```bash
git add <archivos_del_bloque_1>
git commit -m "<tipo>: <resumen breve>" -m "Descripción larga en español: qué cambia, por qué, impacto, alcance."

git add <archivos_del_bloque_2>
git commit -m "<tipo>: <resumen breve>" -m "Descripción larga en español."
```

**Reglas críticas**:
- **No WIP**: nunca commitear "wip", "tmp", código a medias.
- **No mezclar tipos**: no combinar `feat:` + `test:` en un mismo commit.
- **No squash**: los commits individuales se preservan via `--no-ff`. Usar `git log --first-parent master` para ver merges.
- **No rebase interactivo**.

### 3. Ejecutar tests

Obligatorio antes de mergear. Comando depende del stack:

| Stack | Comando |
|---|---|
| Go | `go test ./...` (o con tags si aplica: `-tags goolm` / `-tags fts5`) |
| C++ | `ctest --test-dir cpp/build` |
| Python | `pytest` |
| Sin tests aplicables (solo docs/config) | indicar al usuario y continuar |

Si fallan → **STOP** y corregir. Si pasan → paso 4.

### 4. Evaluar feature flags

Feature flag = código terminado y testeado, **no** código a medias.

Si se modificó `dev/feature_flags.json` o el cambio es parte de feature multi-fase:
1. Verificar que `dev/feature_flags.json` esté actualizado.
2. Confirmar estado correcto del flag (`enabled: true/false`).
3. Incluir el archivo en el commit correspondiente (no commit separado).

Si autocontenido, saltar.

### 5. Cerrar la rama (registry)

```bash
source /home/lucas/fn_registry/bash/functions/infra/tbd_branch_finish.sh
tbd_branch_finish "<descripción corta del merge>"
```

La función:
- Verifica working tree limpio.
- Autodetecta `master`/`main`.
- `git checkout <base>` + `git pull --rebase`.
- `git merge --no-ff <rama> -m "merge: <rama> — <título>"`.
- Si conflicto → exit 2, deja al usuario resolver con `git add` + `git commit` + retry.
- `git push`.
- `git branch -d <rama>`.

### 6. Confirmar al usuario

La función ya imprime `Rama '<rama>' integrada a <base> y publicada. Rama local eliminada.` Repetirlo al usuario.

## Convención de commits

- `feat:` nueva funcionalidad
- `fix:` corrección de error
- `refactor:` cambio estructural sin cambio funcional
- `docs:` documentación
- `chore:` mantenimiento
- `test:` tests nuevos o modificados
- `merge:` commit de merge (lo genera `tbd_branch_finish` con `--no-ff`)

## Regla de mensajes

- Título corto resume el bloque.
- Cuerpo en español: qué se cambió, por qué, qué impacto, qué no se tocó.

## Checklist

- [ ] Cambios commiteados en rama `issue/*` o `quick/*`.
- [ ] Cambios distintos en commits diferentes.
- [ ] Cada commit con descripción larga en español.
- [ ] Tests pasando (o no aplican).
- [ ] Feature flags evaluados (o no aplican).
- [ ] `tbd_branch_finish` ejecutado con éxito.

## Para tocar la lógica de cierre

Editar `tbd_branch_finish_bash_infra` en `bash/functions/infra/tbd_branch_finish.sh`. La parte de tests y commits se queda en este comando porque depende del stack.
