Taller de gestión de código PARTE III (20/10/2014) - Grupo de Verificación - 14/15

Asistentes

• García Nieto, Diego
• León Riego, José Miguel
• Martín Maroto, Sergio
• Pachón Jiménez, Andrés
• Sierra Silva, Samuel
• Utrera Jaén, Daniel

Entregable

• Nuestro proyecto es pequeño en cuanto a diversidad de la funcionalidad, por lo tanto tampoco será necesario crear numerosas ramas durante la realización del proyecto.

• Se generarán ramas para cualquier actividad relacionada con usar librerías desconocidas, intentar mejorar la eficiencia de un método, en definitiva todo lo relacionado con la investigación y mejora de los métodos.

• Cuando en una rama alcanzamos el objetivo por el cual esta fue creada, se procederá a realizar un merge con la rama principal para actualizar el proyecto. Si por lo que fuera no se consigue alcanzar el objetivo o nos damos cuenta de que no convienen estos cambios se desechará la rama. Si al realizar el merge surgen conflictos se mantendrá la versión de la cual realizamos el merge.

• Cuando se realicen cambios sustanciales en el proyecto que merecen ser guardados en el repositorio principal se procederá a realizar un commit, este debe ir acompañado de una descripción detallada de los cambios que se han hecho, los archivos que han sido modificados y el por qué de las modificaciones.

• En cuanto a los derechos, todos tendremos derecho de lectura y escritura sobre todos los archivos, por lo que no habrá roles como tal, se supone que en un proyecto tan pequeño estos roles provocarían demora en el trabajo no teniendo sentido la creación de roles.