Estrategia de Ramas (Branching)

Incluso en proyectos personales, separar el desarrollo de la producción garantiza que el sitio público (dz.log) nunca esté roto.

1. La Rama Principal (main)

Representa la versión Productiva. Todo lo que está aquí se despliega automáticamente en dzamo.gitlab.io. Solo debe recibir cambios mediante merge desde ramas de trabajo.

2. Ramas de Funcionalidad (feature/)

Para cada nuevo módulo, artículo extenso o cambio de diseño, se debe crear una rama temporal.

Flujo recomendado:

1. Crear rama: git checkout -b feature/nueva-nota
2. Trabajar y Commitear: Realizar múltiples commits semánticos.
3. Validar Localmente: Ejecutar npm start para asegurar que no hay errores de MDX.
4. Merge a Main:

   git checkout main
   git merge feature/nueva-nota
   git push origin main

3. ¿Cuándo trabajar directo en main?

En una KB personal, se permite trabajar en main solo para:

• Corregir errores tipográficos (typos).
• Ajustes menores de contenido que no involucren configuraciones de plugins o CSS.
• Actualizaciones rápidas de artículos existentes.

Filosofía DevOps

"Falla rápido, falla seguido... pero en tu entorno local". El uso de ramas de feature permite que experimentes con el diseño del sitio sin interrumpir la disponibilidad de tu Base de Conocimiento para consulta externa.

---

Escenario de Validación Técnica

Requerimiento: Vas a comenzar a documentar el curso de Cloudera. ¿Cuál sería el flujo de Git recomendado?

Resolución Técnica

1. Crear rama: git checkout -b feature/cloudera-module.
2. Crear artículos y usar commits tipo feat(cloudera): ....
3. Validar que el buscador indexa bien en local.
4. Fusionar a main para publicar.