Git Workflow & Convenciones de Repositorios

Convención de Nombres de Repositorios

Patrón

imagy-{domain}[-{qualifier}]

Catálogo de Repositorios

Repositorio	Dominio	Descripción
imagy-identity-gateway	Identity	API Gateway (BFF, OIDC, YARP)
imagy-identity-management	Identity	Tenant Management (Control Plane)
imagy-flow-engine	Flow	Motor de flujos, ejecución, proveedores, reglas
imagy-lending	Lending	Originación, productos, cartera, cobranza
imagy-sign	Sign	Firma digital y electrónica
imagy-subject	Subject	Subject 360, dispositivos, listas
imagy-console	Frontend	Panel administrativo React
imagy-console-public	Frontend	Apps públicas (wizard crédito, ejecución flujos)
imagy-infra	Platform	Infrastructure as Code (CDK/Terraform)
imagy-shared	Platform	Librerías compartidas (.NET)
docs/reimagine-platform	Docs	Documentación central y steerings

Reglas de Naming

• Siempre en lowercase con guiones
• Prefijo imagy- para todos los repos de la plataforma
• El qualifier es opcional y describe el sub-componente
• No usar abreviaciones crípticas
• Repos de documentación van en la carpeta docs/

---

Git Flow

Modelo de Branches

main (producción)
├── develop (integración)
│   ├── feature/{ticket}-{descripcion}
│   ├── fix/{ticket}-{descripcion}
│   └── chore/{ticket}-{descripcion}
├── release/{version}
└── hotfix/{ticket}-{descripcion}

Branch Naming

Tipo	Patrón	Ejemplo
Feature	feature/{ticket}-{descripcion}	feature/IMAG-42-credit-product-config
Bugfix	fix/{ticket}-{descripcion}	fix/IMAG-99-rls-policy-missing
Chore	chore/{ticket}-{descripcion}	chore/IMAG-15-update-dependencies
Release	release/{major}.{minor}.{patch}	release/1.2.0
Hotfix	hotfix/{ticket}-{descripcion}	hotfix/IMAG-101-session-leak

Reglas

• main siempre es deployable a producción
• develop es la rama de integración — todos los features se mergean aquí
• Features se crean desde develop y se mergean a develop via PR
• Releases se crean desde develop cuando hay suficientes features para un release
• Hotfixes se crean desde main y se mergean a main Y develop
• Nunca push directo a main o develop
• Siempre via Pull Request con al menos 1 review

---

Commits

Conventional Commits (obligatorio)

{type}({scope}): {description}

[body opcional]

[footer opcional]

Tipos

Tipo	Cuándo
feat	Nueva funcionalidad
fix	Corrección de bug
docs	Solo documentación
style	Formato (no afecta lógica)
refactor	Refactoring (no agrega feature ni fix)
perf	Mejora de performance
test	Agregar o corregir tests
chore	Mantenimiento (deps, CI, configs)
ci	Cambios en CI/CD

Scope

El scope es el módulo o área afectada:

Scope	Descripción
auth	Autenticación/autorización
tenant	Multi-tenancy
flow	Motor de flujos
lending	Créditos
sign	Firma digital
subject	Subject 360
api	Endpoints REST
db	Base de datos/migraciones
events	Mensajería/eventos
infra	Infraestructura
ui	Frontend

Ejemplos

feat(lending): add credit product configuration endpoint
fix(auth): resolve session leak on backchannel logout
docs(events): document credit.disbursed event schema
refactor(flow): extract provider routing to separate service
test(subject): add integration tests for blacklist queries
chore(deps): update MassTransit to 8.3.0

---

Pull Requests

Template de PR

## Descripción
[Qué hace este PR y por qué]

## Tipo de cambio
- [ ] Feature
- [ ] Bugfix
- [ ] Refactoring
- [ ] Docs
- [ ] Chore

## Checklist
- [ ] Tests agregados/actualizados
- [ ] Documentación actualizada (si aplica)
- [ ] Migraciones de BD incluidas (si aplica)
- [ ] Contratos de eventos actualizados (si aplica)
- [ ] No hay secrets hardcodeados
- [ ] RLS policies cubren nuevas tablas (si aplica)

## Testing
[Cómo se probó este cambio]

## Screenshots (si aplica)
[Capturas de UI]

Reglas de PR

• Título sigue Conventional Commits: feat(lending): add product config
• Mínimo 1 reviewer aprueba antes de merge
• CI debe pasar (build + tests + lint)
• Squash merge a develop (un commit limpio por feature)
• Merge commit a main (preserva historial de releases)

---

Releases y Versionamiento

Semantic Versioning

{major}.{minor}.{patch}

• Major: Breaking changes en API o contratos de eventos
• Minor: Nuevas features backward-compatible
• Patch: Bugfixes

Proceso de Release

1. Crear branch release/X.Y.Z desde develop
2. Solo bugfixes en la release branch (no features nuevos)
3. Merge a main con tag vX.Y.Z
4. Merge back a develop
5. Deploy automático desde main (CI/CD)

Tags

v1.0.0          # Release de producción
v1.0.0-rc.1     # Release candidate
v1.0.0-beta.1   # Beta (para testing)

---

Monorepo vs Multi-repo

Decisión: Multi-repo (un repositorio por servicio/dominio)

Razón	Detalle
Independencia de deploy	Cada servicio se despliega independientemente
Ownership claro	Cada equipo es dueño de su repo
CI/CD simple	Pipeline por repo, no necesita detectar cambios
Permisos granulares	Acceso por repo en GitHub

Excepción: Las librerías compartidas (imagy-shared) son un repo separado publicado como NuGet package interno.

---

Protección de Branches

main

• Requiere PR con 1+ approvals
• Requiere CI passing
• No force push
• No delete

develop

• Requiere PR con 1+ approvals
• Requiere CI passing
• No force push

Feature branches

• Sin restricciones (el developer tiene control)
• Se eliminan después del merge