Iterable 3 (27/10/14)

Asistentes

Asistió	Miembro del grupo
✓	David Álvarez Silva
✓	Antonio Juan Amador Salmerón
✓	Francisco Javier Delgado Vallano
✓	Guiomar Fernandez de Bobadilla Brioso
✓	Jose Luis García Mora
	Sebastián Garrocho Capacete
	Javier Guisado Torres
	Rafael Quesada García

Resultado

• En primer lugar, el administrador del repositorio establece un root branch o rama principal, que será la baseline del proyecto; a partir del cual se va a realizar el desarrollo del mismo.

• Una vez establecido esto, el administrador puede abrir varios branches o ramas en las que se pueden ir desarrollando nuevas funcionalidades paralelamente. Éstos branches serán asignados a diferentes integrantes del grupo a los que se les asignará los permisos correspondientes, ya sea de lectura, escritura o ambos.

• El motivo de crear ramas es el de agilizar el trabajo con el reparto del mismo, de modo que partiendo de la baseline se vayan añadiendo, modificando o probando nuevas funcionalidades.

• La ventaja de esto, esta en que si al desarrollar el branch asignado se encuentra con un error o no puede continuar con el desarrollo, puede volver a la versión almacenada en el root branch. Además de esto, es muy útil a la hora de realizar pruebas, ya que se abre una nueva rama en la que se realizarán las pruebas, mientras que el root branch sigue estable.

• En nuestro caso, todos los usuarios contarán con los permisos tanto de lectura como de escritura.

Las ramas serán creadas con una fecha límite, la cual se corresponde con la fecha establecida en el Sprint correspondiente, por lo que antes de la finalización de dicho plazo el desarrollo a llevar a cabo debería ser completado y por tanto probado para realizar posteriormente un merge. Los merges, es decir, la integración de las nuevas funcionalidades con la rama principal, de modo que dicha rama tendría una nueva versión.

• En el caso de la integración del código con otros subsistemas o merges, solo se realizarán en el caso de que dichos subsistemas sean totalmente estables.