9a77ef59e8
Se añaden las reglas y commands para el flujo trunk-based completo: - fix_issue.md: guía para implementar issues (rama → tests → merge) - git-branch.md: command para crear ramas issue/<NNNN>-<slug> - git-push.md: actualizado con flujo de ramas, tests obligatorios y feature flags - create_issue.md: ajustado formato de numeración a 4 dígitos - index.md: añadida sección de flujo de desarrollo y regla fix_issue - CLAUDE.md: referencia a la nueva regla fix_issue - feature_flags.json: archivo base para flags de despliegue por fases Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.7 KiB
3.7 KiB
Command: git push
Integra cambios a master y publica. Soporta dos flujos segun la rama actual.
Flujo obligatorio
1. Verificar rama actual y estado
git branch --show-current
git status --short
Si estamos en una rama issue/*
Continuar directamente al paso 2.
Si estamos en master con cambios pendientes
Crear una rama automaticamente antes de continuar:
- Preguntar al usuario un nombre descriptivo si no es obvio por los cambios.
- Determinar el siguiente numero de issue disponible (buscar en
dev/issues/ydev/issues/completed/). - Crear la rama:
git checkout -b issue/<NNNN>-<slug>
- Continuar al paso 2 con los cambios ya en la rama nueva.
Si estamos en master sin cambios
STOP: no hay nada que publicar.
2. Revisar cambios y crear commits por bloque
git status --short
git diff --stat
git diff
Si hay cambios de distinta naturaleza, crear varios commits separados por bloque logico:
git add <archivos_del_bloque_1>
git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol explicando que cambia, por que se hizo, impacto esperado y alcance del bloque."
git add <archivos_del_bloque_2>
git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol."
3. Ejecutar tests
Obligatorio antes de mergear. Si el proyecto tiene tests, ejecutarlos:
go test -tags goolm ./...
- Si los tests fallan → STOP: corregir antes de continuar. No mergear codigo roto.
- Si los tests pasan → continuar al paso 4.
- Si no hay tests aplicables (e.g. solo cambios de docs/config) → indicar al usuario y continuar.
4. Evaluar feature flags
Si se modifico dev/feature_flags.json o si los cambios son parte de una feature que se despliega en fases:
- Verificar que
dev/feature_flags.jsonexiste y esta actualizado. - Confirmar que el flag correspondiente tiene el estado correcto (
enabled: true/false). - Incluir el archivo en el commit correspondiente (no crear commit separado solo para flags).
Si no aplican feature flags, saltar este paso.
5. Actualizar master y hacer merge --no-ff
git checkout master
git pull --rebase
git merge --no-ff issue/<NNNN>-<slug> -m "merge: issue/<NNNN>-<slug> — <titulo breve>"
El merge commit debe tener formato:
- Titulo:
merge: issue/<NNNN>-<slug> — <descripcion corta> - Cuerpo (opcional): resumen de lo que entra
Si hay conflictos durante el merge:
- Resolver los conflictos
git addlos archivos resueltosgit commit(sin -m, para mantener el mensaje de merge)
6. Push a remoto
git push
7. Limpiar rama local
git branch -d issue/<NNNN>-<slug>
8. Confirmar al usuario
Rama `issue/<NNNN>-<slug>` integrada a master y publicada.
Rama local eliminada.
Convencion de commits
feat:nueva funcionalidadfix:correccion de errorrefactor:cambio estructural sin cambio funcionaldocs:documentacionchore:mantenimientotest:tests nuevos o modificadosmerge:commit de merge (generado por --no-ff)
Regla de mensajes
- El titulo (
-mcorto) debe resumir el bloque. - El cuerpo (
-mlargo) debe estar en espanol y explicar:- que se cambio,
- por que se cambio,
- que impacto tiene,
- que no se toco.
Checklist rapido
- Todos los cambios estan commiteados en una rama
issue/*. - Se separaron cambios distintos en commits diferentes.
- Cada commit tiene descripcion larga en espanol.
- Tests ejecutados y pasando (o no aplican).
- Feature flags evaluados (o no aplican).
git merge --no-ffejecutado desde master.git pushejecutado correctamente.- Rama local eliminada.