Análisis de procesos de Git del equipo, pedido por Edu (sesión 101, 02-06-2026). Dos problemas reincidentes diagnosticados con evidencia real del reflog, las medidas definitivas adoptadas, y su automatización en el harness para que sean convergencia automática, no recordatorios humanos. Compartido con los 3 Claudes del staff (staff-share).

Problema 1 · El here-string de PowerShell rompe mensajes de commit

Al hacer commits multilínea en PowerShell se usaba el here-string @'...'@. Esa sintaxis exige que el '@ de cierre esté en columna 0, sin un solo espacio delante. Cuando se desalinea, PowerShell interpreta solo el @ literal como mensaje y crea un commit con mensaje basura, aunque el commit “tenga éxito”.

Evidencia real (no teórica):

• Reflog s101: 5f43f436 HEAD@{1}: commit: @ → mensaje literal @, rescatado después con --amend.
• Grafo s96: bcde7111 @ docs(s96)... y c711907d @ feat(signage)... → mismo síntoma semanas antes.

Fix (definitivo)

Prohibido el here-string para mensajes de commit. Alternativas robustas:

git commit -m "fix(x): titulo corto" -m "Parrafo de cuerpo opcional."   # cada -m = un parrafo
git commit -F mensaje.txt                                                # mensajes largos

Anclado en CLAUDE.md §6 y en claude-method/workflow/git-flow.md (auto-pull a los 3 perfiles).

Problema 2 · Conflictos de docs en cada rebase/merge

Tres personas editan en cada sesión los mismos docs vivos (CLAUDE.md, TASK.md, CHANGELOG.md, RELEASE_NOTES.md, README.md) y casi siempre en las mismas líneas (versión, fecha, “última actualización sNN”). Concurrencia plana → conflicto garantizado. El churn no viene del código: en 30 días, 58 commits docs vs 52 fix y 41 feat.

Fix

merge=union no debe usarse en docs in-place (CLAUDE/TASK/README): duplicaría líneas.

Automatización · convergencia sin error humano (Capa 2)

Petición de Edu: “no depender de que Dani y Txell se acuerden de la instrucción en git; la mejor manera de minimizar el error humano es la sincronización en segundo plano.” El claude-method ya tenía el patrón (pasos idempotentes que “corren SIEMPRE” en claude-method-sync.ps1: gate Regla 0 = 0.5, hooks vivos = 0.55). Se añadieron dos pasos más.

Paso 0.65 · Config git del equipo converge sola. Tabla declarativa $teamGitConfig (hoy: rerere.enabled + rerere.autoupdate) aplicada a --global en cada arranque, idempotente, en los 3 perfiles. rerere ya no se activa a mano. Añadir config futura = una línea.

Paso 0.7 · Pre-push determinista (“main es una roca”). Hook pre-push (claude-method/harness/pre-push.hook, instalado idempotente por install-git-hooks.ps1). Antes de cada push a main hace git fetch y, si origin/main avanzó desde tu base, aborta con un mensaje claro (cuántos commits y de quién). Así main nunca recibe un push sobre base vieja.

La señal la recibe Claude, no una terminal aparte. Como el git push lo ejecuta Claude vía la herramienta Bash, el mensaje del hook vuelve a Claude en el resultado del comando → Claude hace git pull --rebase (rerere auto-resuelve los docs) y reintenta. Transparente para el dev. Esto fusiona la detección de divergencia en el propio proceso de push (idea de Edu), evitando el auto-rebase en segundo plano, que se descartó por mover el árbol bajo los pies mientras editas.

Observación de fondo

El flujo del equipo es disciplinado: branch por hito → PR → merge limpio. El problema no es el flujo de ramas, es el merge de los docs vivos y el push sobre base vieja — y eso es justo lo que blindan las medidas, ahora de forma automática. La disciplina de Regla 3 (docs en cada commit) se mantiene; solo se protege su fusión.

Última actualización: 02-06-2026 (s101). Origen: análisis de Git pedido por Edu. Capa 1 (config + docs) + Capa 2 (automatización en el harness).