Gestión del código - ISPPNightTurn/Clubby GitHub Wiki

El repositorio se va a dividir en ramas, de forma que quedaría:

• master: Nadie podrá realizar commits directamente en esta rama, una vez el proyecto haya empezado. Únicamente se permitirán Pull Requests desde la rama develop una vez que se estabilicen todos los cambios.
• develop: Rama para concentrar todos los cambios de los distintos miembros. Una vez se estabilicen pasaran a la rama master para posteriormente realizar una nueva versión.
• feature: Ramas que serán usadas para dessarrollar la nueva funcionalidad. Tras su prueba y verificación, se harán Pull-Request a develop para mergear los cambios y continuar con el trabajo restante.

La persona encargada de realizar la característica pertinente tendrá que hacer una solicitud mediante Pull-Request. Una vez esta persona, o aquellas encargada de comprobar los Pull-Request, hayan verificado dicha petición, se realizará el merge a la rama develop.

[<tipo>] <Titulo>
# Línea en blanco
<Descripción>
# Línea en blanco
<Pie>

• Tipo: Los valores permitidos serán:
  • feat: Nuevas funcionalidades.
  • fix: Reparaciones de bugs.
  • docs: Cambios en documentación.
  • style: Formateo, falta de ; por ejemplo, pero sin cambios en el código.
  • refactor: Refactorización del código.
  • test: Nuevos tests, refactorizar los existentes. Sin cambios en el código de producción.
• Titulo: Breve y conciso. Expresa la idea general en una línea. Preferencia por participios, infinitivos y sustantivos.
• Descripción: Campo opcional. Debe contar con un nivel de detalle suficiente como para que los demás miembros puedan comprender los cambios realizados.
• Pie: Campo opcional. Indicar las incidencias que se cierran usando el prefijo Closes y el número de la incidencia precedido por la #. Como ejemplo Closes #431. Si hay más de una Closes #231, #132.

Cuando una funcionalidad esté terminada, se abrirá una Pull-Request a develop. Dicha Pull-Request tendrá varios asignados. El primer asignado será el desarrollador de la funcionalidad, que tendrá que verificar que dicha funcionalidad funciona correctamente. Un segundo asignado será otro compañero perteneciente al equipo de desarrollo, que tendrá que comprobar también que la funcionalidad implementada funciona correctamente.

El Pull-Request será creado por uno de los desarrolladores, preferentemente el jefe del equipo de desarrollo. Dicho Pull-Request, para que su realización sea óptima, deberá ser creado con todos los desarrolladores reunidos, en persona o vía telemática, para disminuir las posibilidades de presencia de bugs.

Las ramas se eliminarán semanalmente cuando se haga el merge hacia develop y todo esté correcto. En caso de que haya que arreglar o añadir alguna mejora, crear la issue con el mismo nombre de feature que la anterior pero en vez de indicar feature, indicar fix.

Las etiquetas en los Pull-Request serán obligatorias desde cada rama feature a develop.

feature/descripcionFeature

fix/descripcionFix

En caso de que el Pull-Request no supere las pruebas, mediante comentarios en el mismo Pull-Request se indica el problema y se arregla, para que la comunicación sea rápida y fluida.

El Pull-Request se actualiza automáticamente al hacer un nuevo commit, por lo tanto no es necesario cerrarlo y volverlo a abrir.

1. Esta plantilla contiene elementos adaptados de la guía Karma - Git Commit Msg