Objetivo del tema: que nadie vuelva a escribir a mano un comando de git del día a día. Al acabar, todo lo de git pasa por la skill /git-flow.

Lo que ya sabéis y aquí no se repite:

• Git básico, .gitignore y el formato de los mensajes de commit type(#issue):título: Despliegue 1.
• Ramas, los tipos de merge, conflictos y, sobre todo, worktrees y por qué uno por rama cuando se trabaja con agentes: Despliegue 2.
• Scrum y los tableros de GitHub: Proyecto 4.

Todo trabajo empieza por un issue. El issue es la unidad: de él sale la rama, su número va en los commits y al fusionar se cierra solo.

El tablero es un GitHub Project del repositorio con tres columnas: Todo, In progress y Done. De sus automatizaciones (Workflows del proyecto) solo hace falta una, que viene activada de serie: issue cerrado → Done. El resto se hace a mano: al crear el issue se añade al tablero, y al empezar a trabajarlo se arrastra a In progress. Automatizar eso por línea de comandos no compensa.

Etiquetas: feature y bug. No hacen falta más.

Los issues se crean desde la web o con gh:

gh issue create --title "Alta de clientes" --label feature --body "Formulario de alta con nombre, NIF y email."
gh issue list
gh issue view 12

El modelo de ramas de Despliegue 2 tiene develop, release y master. Aquí, al ser un proyecto individual con un solo entorno, se recorta a dos:

• develop: la integración. Solo existe de verdad en local, en la carpeta principal del repositorio; en GitHub está porque es la rama por defecto y es donde se cierran los issues. Nunca se despliega.
• main: producción. Cada push a main despliega en el servidor (tema 6). Nunca se trabaja en ella.

Y por cada issue, una rama de trabajo en su propio worktree:

El número del issue en el nombre de la rama hace que la skill sepa siempre a qué issue pertenece, sin preguntarlo.

Sin pull requests. En un proyecto individual nadie va a revisar el PR, así que es un trámite que no aporta nada: la rama se fusiona en develop en local y se hace push. La revisión del código la hará la IA antes de fusionar (tema 5).

1. Iniciar: desde la carpeta principal (siempre en develop, actualizada), crear la rama y su worktree.
2. Trabajar en el worktree. Commits pequeños con type(#N):título.
3. Actualizar: si develop ha avanzado (otro issue que se ha terminado antes), traer develop a la rama con git merge develop. Los conflictos se resuelven en la rama, nunca en develop.
4. Finalizar: fusionar en develop con –squash: todos los commits de la rama se funden en uno con el mensaje feat(#N): título. Push de develop. Borrar el worktree y la rama.
5. Publicar: cuando hay algo que sacar, develop → main con –ff-only y push.

Por qué –squash hacia develop y –ff-only hacia main está en Usos de merge.

GitHub cierra un issue automáticamente cuando llega a la rama por defecto un commit cuyo mensaje contiene Closes #N. Por eso develop es la rama por defecto, y por eso el commit de la fusión lleva el Closes en el cuerpo:

feat(#12): Alta de clientes

Closes #12

Al hacer push de develop, el issue 12 se cierra y el tablero lo pasa a Done. No hay que tocar nada en la web.

Una skill que ejecuta git puede hacer daño si improvisa. Estas reglas van en la skill y no se negocian:

• Nunca git pull. Siempre git fetch –prune y git merge –ff-only origin/<rama>. Así, si las historias han divergido, falla en vez de hacer un merge sorpresa.
• Nunca –force, ni –no-verify, ni stash, ni borrar worktrees con –force.
• Nunca resolver un conflicto. Si un merge da conflicto, la skill se para, enseña git status y dice qué comandos tiene que ejecutar el alumno. Resolver conflictos es trabajo humano.
• La carpeta principal siempre en develop y limpia. Si no lo está, la skill se para antes de hacer nada.
• Una operación por invocación: /git-flow iniciar 12, no «inicia y luego finaliza».
• allowed-tools como lista blanca: solo git y gh. Nada de rm, nada de escribir ficheros del proyecto.

Se parte de la skill que ya enlaza Despliegue 2, git-flow-skill.md, que es casi lo que hace falta. Pedir al agente que la adapte con estos cambios:

• Quitar release, bajar y subir. Quedan cinco operaciones:

• El nombre del alumno para las ramas se lee de AGENTS.md (una línea: «las ramas empiezan por lorenzo-»).
• Añadir Bash(gh issue view:*) a allowed-tools.
• finalizar y actualizar deducen la rama del worktree en el que se ejecutan, como ya hace la skill original.

En el tema 3 iniciar y finalizar crecen para levantar y parar los contenedores, y en el tema 5 finalizar lanza antes la revisión por IA.

Prueba: crear dos issues pequeños (por ejemplo, «Página de inicio con el nombre del proyecto» y «README con cómo arrancar»), iniciarlos los dos, trabajarlos en paralelo en sus dos worktrees, hacer sus commits con /git-flow commit, finalizarlos y comprobar en GitHub que los issues se han cerrado y están en Done. Después /git-flow publicar: main avanza, aunque todavía no despliega nada.