Git workflow

Fuente

Convenciones generales de la organización, definidas en Industrias-CTS/.github. Aplican a todos los departamentos, no solo a DDS.

Estrategia de ramas

main → develop → feature/xxx

• main — versión estable.
• develop — integración del trabajo en curso.
• feature/xxx — una rama por funcionalidad, sale de develop.

La convención no se cumple: hay tres esquemas distintos en uso

Repositorio	Rama de trabajo real	Coincide con la convención
devices-recognizer	developer	❌
t-monitor	production	❌
modbus-manager	production	❌
custom-rpi-images	production	❌

Los runbooks documentan la rama correcta de cada repositorio, porque trabajar sobre la equivocada produce archivos o binarios que no corresponden a la versión vigente:

• Habilitar cuenta de m-system → developer
• Configurar una pantalla HMI → production

Hay que decidir una sola convención y aplicarla, o dejar la convención de la organización como referencia y documentar cada excepción de forma explícita. Hoy alguien nuevo no puede adivinar la rama correcta de un repositorio: tiene que preguntar.

Commits

Mensajes descriptivos, en español o en inglés.

Pendiente

Definir si se adopta un formato más estricto (por ejemplo Conventional Commits) o se mantiene la regla actual.

Merge

• Mínimo 1 aprobación antes de hacer merge. Ver Code review.

Pendiente

Definir la estrategia de merge (squash, merge commit o rebase) y qué reglas de protección están configuradas en main y develop.

Repositorios nuevos

• Nombre: prefijo por área cuando aplique — por ejemplo pae-proyecto.
• README: obligatorio y actualizado.
• CLAUDE.md: debe estar en la raíz del repositorio y mantenerse actualizado.
• Registrar el repositorio en el perfil de la organización (Industrias-CTS/.github) y en el Mapa de sistemas.

Qué nunca va al repositorio

Secretos, archivos .env con valores reales, llaves privadas y certificados.

Si se filtró un secreto

Borrarlo del código no basta: queda en el historial de Git. Hay que rotar la credencial primero y después limpiar el historial.