Este repositorio es el entorno de prácticas oficial para la asimilación del flujo de trabajo con Git, revisión de código por pares (Peer Review) y familiarización con la estructura de documentación estática (Vitepress).
El objetivo es modificar colaborativamente una web estática de presentación del equipo mediante la resolución de 12 Issues predefinidos, enfrentándose a la sincronización de ramas y resolución de conflictos.
├── docs/
│ ├── .vitepress/ # Configuración del generador de sitios estáticos
│ └── src/ # Raíz de contenido Vitepress (srcDir)
│ ├── index.md # Landing page del equipo (A modificar)
│ ├── team.md # Perfiles y hobbies de los miembros (A modificar)
│ ├── contact.md # Directorio de contacto institucional (A modificar)
│ └── backlog/ # Definición de los 12 issues
│ ├── F-01.1.md
│ ├── ...
│ └── F-01.12.md
└── README.md # Este archivo
Existen 12 Issues registrados en el tablero del proyecto, divididos por prioridad MoSCoW:
- 6 Prioridad
Must: Requisitos obligatorios (datos de presentación básicos, contacto, stack…). - 6 Prioridad
Should: Requisitos recomendados (hobbies, recomendaciones, objetivos…).
Cada desarrollador asumirá 2 issues (1 Must + 1 Should). La definición completa de cada issue, con el bloque de código a insertar y los Criterios de Aceptación, está en docs/src/backlog/.
Antes de tocar ningún archivo, hay que gestionar el trabajo desde el tablero del proyecto en GitHub.
El tablero se llama "Demo Kanban" y tiene las siguientes columnas:
| Columna | Significado |
|---|---|
| Backlog | Issues disponibles, aún sin asignar |
| Ready | Issues asignados y listos para empezar |
| In Progress | Issue en el que estás trabajando ahora mismo |
| In Review | PR abierto, esperando revisión de un compañero |
| Done | PR aprobado y mergeado a develop |
- Ve a la página principal del repositorio en GitHub.
- Haz clic en la pestaña "Projects" (barra superior del repo).
- Selecciona el proyecto "Demo Kanban".
Desde el tablero Backlog:
- Localiza un issue de prioridad Must (etiqueta verde
Must) que nadie haya reclamado aún. - Haz clic sobre él para abrir el panel lateral.
- En la sección "Assignees" (lado derecho), haz clic y selecciónate a ti mismo.
- Cambia el estado del issue en el tablero arrastrándolo a la columna Ready, o usando el desplegable de estado en el panel lateral.
- Repite los pasos 1–4 con un issue de prioridad Should.
⚠️ No te asignes más de 1 Must y 1 Should. El tablero es visible para todo el equipo.
Ejecuta este ciclo una vez por cada issue asignado. Empieza siempre por el Must.
Antes de escribir una sola línea de código:
- Abre el tablero Demo Kanban.
- Arrastra el issue con el que vas a empezar desde Ready a In Progress.
Solo debe haber un issue en In Progress a la vez por persona.
Asegúrate de partir siempre de la rama de integración (develop) actualizada:
git checkout develop
git pull origin developCrea tu rama siguiendo la convención de nombres:
git checkout -b feature/F-01.X-<tu-alias>
# Ejemplo: git checkout -b feature/F-01.1-guillermo-garrido- Abre el archivo del issue correspondiente en
docs/src/backlog/F-01.X.mdy lee los Criterios de Aceptación. - Copia el bloque Markdown preparado en el issue y pégalo en el archivo indicado (
team.md,contact.mdoindex.md). - Sustituye todos los valores entre
< >por tu información real. - Añade al final de tu bloque la sección obligatoria:
## UserManual
<Explica brevemente qué bloque añadiste y cómo otro miembro podría replicarlo>Una vez guardados los cambios:
git add .
git commit -m "feat(team): añadir <descripción breve> de <TuNombre> (Closes #X)"
# Ejemplo: git commit -m "feat(team): añadir tarjeta básica de Guillermo Garrido (Closes #1)"
git push -u origin feature/F-01.X-<tu-alias>La referencia
Closes #Xvincula automáticamente el commit con el issue en GitHub.
Dado que varios compañeros están modificando los mismos archivos a la vez, antes de abrir el PR debes incorporar los últimos cambios integrados:
# Actualiza tu información de las ramas remotas
git fetch origin
# Trae los cambios de develop a tu rama actual
git pull origin developSi Git detecta un conflicto de merge, verás algo como esto en el archivo afectado:
<<<<<<< HEAD
Tu contenido
=======
Contenido de tu compañero
>>>>>>> origin/develop
Para resolverlo:
- Abre el archivo en tu editor.
- Decide qué contenido se queda (normalmente ambos bloques, uno después del otro).
- Elimina las líneas
<<<<<<<,=======y>>>>>>>. - Guarda el archivo.
- Registra la resolución y completa el merge:
git add .
git commit -m "merge: resolver conflicto en team.md con develop"Con tu rama ya sincronizada, súbela y abre el PR:
git push origin feature/F-01.X-<tu-alias>Ahora, en GitHub:
- Ve a la pestaña "Pull requests" del repositorio.
- Haz clic en "New pull request" (o en el botón amarillo que aparece automáticamente).
- Configura el PR:
- base:
develop← compare:feature/F-01.X-<tu-alias>
- base:
- Ponle un título descriptivo:
feat(team): añadir tarjeta básica de Guillermo Garrido - En la descripción escribe
Closes #X(número del issue). - En la sección "Reviewers" (panel derecho), asigna al compañero de la derecha de tu equipo.
- Haz clic en "Create pull request".
Por último, mueve el issue en el tablero Demo Kanban a la columna In Review.
Ahora repite el proceso completo (pasos 1–6) con tu issue de prioridad Should.
Mueve el issue Should a In Progress en el tablero antes de empezar. Recuerda que el Must debe estar ya en In Review.
Cuando un compañero te asigne como Reviewer en su PR, recibirás una notificación en GitHub. Sigue estos pasos:
-
Ve a la pestaña "Pull requests" del repositorio.
-
Abre el PR que te han asignado.
-
Haz clic en la pestaña "Files changed" para ver exactamente qué líneas se han modificado.
-
Descarga la rama del compañero para comprobarla en local (opcional pero recomendado):
git fetch origin git checkout feature/F-01.X-<alias-compañero>
-
Revisa el contenido bloque a bloque según los Criterios de Aceptación del issue correspondiente (en
docs/src/backlog/F-01.X.md).
- En el PR, haz clic en "Review changes" (botón verde arriba a la derecha de "Files changed").
- Selecciona "Approve" y escribe un comentario breve de confirmación.
- Haz clic en "Submit review".
- Haz clic en "Merge pull request" → "Confirm merge" para integrar los cambios en
develop. - Mueve el issue en el tablero Demo Kanban a la columna Done.
- En el PR, haz clic en "Review changes".
- Selecciona "Request changes".
- En el comentario, indica qué criterio de aceptación no se cumple y porque.
- Haz clic en "Submit review".
- El autor del PR recibirá la notificación, corregirá en su rama local, hará un nuevo commit y subirá los cambios. El PR se actualizará automáticamente.
- Repite la revisión hasta aprobar.
No hagas merge si algún criterio no está cumplido. La revisión por pares es parte de la evaluación.
flowchart TD
A([Backlog]) -->|Te asignas 1 Must + 1 Should| B([Ready])
B -->|Empiezas con el Must| C([In Progress])
C --> C1["git checkout -b feature/F-01.X-tu-alias\ngit add . && git commit && git push\ngit pull origin develop"]
C1 -->|Abres PR hacia develop + asignas Reviewer| D([In Review])
D -->|Cambias al Should| C2([In Progress])
C2 --> C3["mismo ciclo: rama → commit → push → PR"]
C3 --> D2([In Review ×2])
D2 -->|Compañero aprueba → Merge| E([Done ✅])