Ejercicio 4. Barbacoa en GitLab

Objetivo

• Organizar una barbacoa con Git empleando un servicio de alojamiento Git: GitLab
• Modelo: distribuído. Colaboradores hacen repos derivados (fork) y contribuyen mediante solicitudes de integración de ramas (merge requests).
• La información se escribe en formato asciidoc, similar a markdown. Permite generar fácilmente html, pdf, etc. y es adecuado para control de versiones.
• Repo inicial con varios archivos:
  • comida.adoc: comidas a llevar
  • bebida.adoc: bebidas a llevar
  • materiales.adoc: materiales necesarios (sillas, mesas, etc.)
  • asistentes.adoc: lista de personas que van a ir. Quien pueda llevar coche que lo indique y que se apunten abajo sus acompañantes.
  • juegos.adoc: propuestas de juegos para llevar a la barbacoa.
  • etc.

Datos del repositorio y recursos de comunicación

• Grupo 1:
  • Repositorio: https://gitlab.com/jjchico/barbacoa-g1.git
• Grupo 2:
  • Repositorio: https://gitlab.com/jjchico/barbacoa-g2.git

Flujo de trabajo

El ejercicio se reliza siguiendo un flujo de trabajo con varios desarrolladores y un integrador (el profesor).

• El profesor crea el repositorio principal en GitLab y crea algún contenido inicial.
• El alumno abre una cuenta en GitLab.
• En GitLab crea un repositorio derivado del principal (fork) y lo hace público o interno.
• Clona su repositorio derivado localmente y registra cambios en una rama distinta a "master".
• Sube los cambios en la rama de desarrollo a su repositorio público en GitLab.
• Dentro de GitLab hace una solicitud de integración (merge request en terminología de GitLab) de la rama donde ha hecho sus modificaciones con la rama master del repositorio principal.
• Comprueba si su solicitud ha sido aceptada o rechazada,  lee los comentarios del profesor y actúa en consecuencia.
• El alumno actualiza su rama local master desde la rama master del repositorio principal para incorporar los cambios del profesor y de otros alumnos. Para ello se recomienda añadir un remoto adicional de nombre upstream que corresponda al repositorio principal publicado por el profesor.

Flujo alternativo

En opinión del profesor, GitLab ofrece un servicio honesto, útil, y no intrusivo para el usuario. No obstante, si el alumno prefiere por algún motivo no abrir una cuenta en este proveedor, puede coordinarse con el profesor para acordar una mecánica alternativa que no precise abrir una cuenta en este servicio.

Tareas a realizar

Respecto a la configuración en GitLab

• Abrir una cuenta.
• Clonar el repositorio del profesor dentro de GitLab (fork).
• (Recomendado) Subir la clave pública ssh para facilitar el acceso al servidor.
• (Opcional) Instalar la aplicación Labcoat (Android) para acceder a GitLab desde el móvil.

Cambios mínimos en el proyecto

• Modificar lista de asistentes para incluirse en la misma.
• Añadirse a la lista de algún transporte en la lista de asistentes.
• Añadir algún dato o hacer algún cambio en: bebidas, comidas, materiales, juegos, etc.
• Al final, el alumno deberá tener al menos tres peticiones de integración aceptadas.

Los alumnos pueden hacer tantas solicitudes de integración como quieran. Se recomienda proponer cambios durante varios días.

Los cambios propuestos deben ser lógicos (tratar sobre un tema concreto) y estar bien documentados (mensajes significativos y descriptivos). De no ser así, las propuestas de integración serán rechazadas.

Otros cambios y tareas

• Crear un archivo README.adoc con una breve descripción del proyecto, autores y licencia.
• Emplear el sistema de informe de errores de GitLab para coordinar propuestas de cambios, sugerencias, etc.

Entrega

• Al final del ejercicio, generar un informe dentro de la misma carpeta del proyecto con los siguientes comandos:

$ git config user.name > informe.txt
$ git config user.email >> informe.txt
$ git remote -v >> informe.txt
$ git branch -vv >> informe.txt

• Entregar el archivo generado al profesor mediante EV o el canal alternativo que se indique.