Git, branches, PRs y trabajo multiagente
main/dev/working branch, PR/diff, Pre-Merge Audit, protección técnica/lógica, contratos de concurrencia, interfaces compartidas, Break-Glass y Merge Authority.
main/dev/working branch, PR/diff, Pre-Merge Audit, protección técnica/lógica, contratos de concurrencia, interfaces compartidas, Break-Glass y Merge Authority.
Git es parte del contrato durable de trabajo. DCP Flow usa branches, PRs y evidencia para coordinar humanos y agentes sin depender de memoria de sesión.
Gobernanza del repositorio
El patrón main / dev / working branch separa producción, integración y trabajo acotado. Pre-Merge Audit, Merge Authority, Technical Protection y Logical Protection aseguran que integrar un cambio sea una decisión revisable.
- main, dev y working branches.
- PR y diff como superficie de revisión.
- Pre-Merge Audit.
- Merge Authority y Break-Glass.
Trabajo multiagente
Concurrency Contracts, Shared Interfaces e Integration Order reducen colisiones. DCP Flow diferencia Git Conflict de Functional Conflict: un merge limpio no garantiza que dos cambios funcionen correctamente juntos.
- Temporal ownership.
- Shared Interfaces.
- Integration Order.
- Git Conflict ≠ Functional Conflict.
Git convierte trabajo temporal en estado técnico reconstruible
DCP Flow usa main como baseline estable/release, dev como integración permanente y working branches como unidades temporales de trabajo. El PR hace visibles origen, destino, commits, diff, checks y discusión. Antes de integrar una working branch a dev, Pre-Merge Audit revisa scope, arquitectura, tests, seguridad, documentación, Quality Gates, conflictos y riesgo.
- main = stable/release.
- dev = integration baseline.
- working branch = bounded work unit.
- PR created ≠ merge authorized.
Logical Protection conserva la regla cuando la plataforma no puede imponerla
Branch Protection o Rulesets son preferibles cuando están disponibles, pero su ausencia no elimina la gobernanza. Logical Protection mantiene no direct development en ramas permanentes, no force push, audit before merge, dev como origen normal de main y Human Gate para release. Los agentes deben tratar estas restricciones procedimentales como límites reales.
- Platform cannot enforce ≠ rule does not exist.
- No force push en main/dev.
- Working branch → dev primero.
- CAN MERGE ≠ AUTHORIZED TO MERGE NOW.
Trabajo multiagente requiere Concurrency Contract e integración funcional
Dos agentes pueden avanzar en paralelo cuando ownership temporal, branches, módulos, interfaces compartidas, dependencias e Integration Order están suficientemente claros. Un Git Conflict es textual; un Functional Conflict puede romper el sistema aunque el merge sea limpio. Después de integración material también puede requerirse Post-Merge Validation sobre el SHA real resultante.
- Temporal ownership reduce overlap.
- Shared Interfaces elevan riesgo de coordinación.
- Git Conflict ≠ Functional Conflict.
- Post-Merge Validation verifica el estado integrado real.
Glosario contextual＋
Working Branch
Revisión previa a integración que busca conflictos, regresiones, deuda conocida y evidencia faltante.
Concurrency Contract
Merge Authority