Flujo de Trabajo en Git (Git Workflow)

Para el desarrollo de DiagAuto, sigo un flujo de trabajo estructurado basado en ramas de funcionalidades (Feature Branches) integradas de forma secuencial hacia la rama principal. Esto me permite aislar los experimentos, mantener un historial limpio y automatizar las pruebas de integración continua de manera ordenada.

%%{init: { 'gitGraph': { 'mainBranchName': 'main' } } }%%
gitGraph
    commit id: "Initial project setup"
    branch feat/vehicle-limit
    commit id: "feat: update signal for freemium count"
    commit id: "feat: build paywall guard"
    commit id: "test: check 4 cars block logic"
    checkout main
    merge feat/vehicle-limit id: "merge into main via PR"
    commit id: "chore: update environment urls"

---

⚙️ Configuración inicial de desarrollo (Solo una vez)

git clone https://github.com/diagAuto-frontend
cd diagAuto-frontend
# Configurar la rama principal por defecto
git checkout main

---

🛠️ Ciclo de trabajo diario para implementar una tarea

Para codificar cualquier funcionalidad, corrección de errores o configuración, sigo estrictamente los siguientes pasos en la terminal:

# Asegurar que la rama principal local tiene los últimos cambios del servidor
git checkout main
git pull origin main

# Crear y cambiar a una rama específica para la tarea
git checkout -b feat/descripcion-corta-en-ingles

# Commits atómicos: un archivo o paso lógico a la vez
git add src/app/features/vehicles/components/vehicle-card.component.ts
git commit -m "feat: add visual alert badge for faulty status"

# Una vez terminada y probada la tarea en local, subir la rama a GitHub
git push origin feat/descripcion-corta-en-ingles

1. Abrir una Pull Request (PR) en GitHub: Navego a mi repositorio y abro una PR comparando main ← feat/descripcion-corta. Esto dispara de forma automática la pipeline de GitHub Actions para validar que todos los test unitarios sigan pasando y que se mantenga el umbral de cobertura mínimo (coverage threshold).
2. Fusión y Limpieza: Tras la verificación exitosa de la integración continua, fusiono la PR en la interfaz web de GitHub y limpio mi espacio de trabajo local:

# Sincronizar los cambios mezclados de vuelta a mi máquina local
git checkout main
git pull origin main

# Eliminar la rama local que ya fue integrada para mantener el árbol limpio
git branch -d feat/descripcion

---

📁 Nomenclatura de Ramas (Branch Naming)

Los nombres de las ramas se escriben en inglés, minúsculas y utilizando guiones para separar palabras (kebab-case), precedidos por su respectivo prefijo utilitario:

Prefijo	Uso	Ejemplo real
feat	Nuevas funcionalidades o lógicas de negocio	feat/paywall-freemium-limit
fix	Corrección de fallos visuales o lógicos de código	fix/auth-cookie-refresh
chore	Actualizaciones de configuración, herramientas o tokens de Tailwind	chore/add-tailwind-theme-tokens
test	Inserción o modificación exclusiva de suites de pruebas	test/add-agenda-signals-specs

---

📝 Mensajes de Commit (Commit Messages)

Se sigue estrictamente el estándar internacional de Conventional Commits. Los mensajes se escriben en inglés, comenzando con el tipo de acción en minúsculas seguido de dos puntos y una descripción directa en imperativo:

feat: integrate subscription checkout service connector
fix: enforce disabled attribute on vehicle submit when plan is limited
test: mock private vehicles query for user agenda test suite
chore: upgrade packages to angular 19 functional stable releases

---

🏁 Gestión de Pull Requests

• Título: Escrito en inglés, claro y conciso sobre el cambio introducido (ej: “feat: lock vehicle registry form after 4th car”).
• Descripción: Breve resumen técnico de qué ha cambiado, por qué era necesario y qué comandos ejecutar para verificar que funcione visualmente.
• Integración: Aunque sea un proyecto individual, fusionar el código a través de PRs garantiza un historial de Git impecable y asegura que nunca introduzco código roto a la rama main gracias a los tests automatizados en la nube.