El primer paso para unificar la UI es hacer un Fork del repositorio gitlab Portal UI para ello se debe poner un Jira a MNCS (DJ-AT-MNCS) indicando que se quiere hacer dicho Fork. Cada grupo tendrá un único Fork para la UI unificada del Portal de Servicios, y dentro de ese Fork se deberá trabajar de manera coordinada en los diferentes proyectos para evitar conflictos en los despliegues.
Si se trabaja en proyectos independientes, las subidas entre los diferentes proyectos no deberían interferir en el funcionamiento de la UI en la que estemos trabajando, pero sí tendremos que acordarnos de permanecer siempre sincronizados con nuestro Fork. De la misma manera cada Fork tendrá un entorno de despliegue que NO es el de POSE, sino uno propio para ese Fork donde podremos probar nuestro código antes de unificar en la rama de desarrollo de POSE.

La dirección de los repositorios, tanto al hacer "git clone" como al hacer "git remote add upstream" depende de que hemos configurado git para que se autentique con usuario y clave (usaríamos https://gitlab.um.es/...) o con certificado (usaríamos git@gitlab.um.es:...).
Si estamos usando usuario y clave:
$ git clone https://gitlab.um.es/XXXX/portal-ui.git $ cd portal-ui $ git remote add upstream https://gitlab.um.es/aulavirtual/portal-ui.git |
Si estamos usando certificado:
$ git clone git@gitlab.um.es:XXXX/portal-ui.git $ cd portal-ui $ git remote add upstream git@gitlab.um.es:aulavirtual/portal-ui.git |
$ git checkout master # Me cambio a master $ git pull origin master # Actualizo el proyecto, desde el fork de mi grupo $ git pull upstream master # Actualizo el proyecto desde el proyecto original del portal # ¡IMPORTANTE!: Antes de hacer un push de la rama master, debemos siempre comprobar que no hayamos # hecho por error un commit en dicha rama. En caso de duda no ejecutaremos el siguiente comando. $ git push origin master # Actualizo la rama master del fork de mi grupo |
Es posible que nos diga que no tenemos permisos para ejecutar el comando "git push origin master", este comando no es necesario, aunque es recomendable mantener el repositorio de nuestro grupo actualizado.
La idea es mantener la rama master sincronizada con lo que hay en el repositorio remoto de aulavirtual (upsteam), por lo tanto no deberíamos hacer cambios en master, solamente actualizarlo con los cambios de upstream.
$ git checkout -b jira-XXXX |
$ git checkout master # Me cambio a master $ git pull origin master # Actualizo el master desde el fork de mi grupo $ git pull upstream master # Actualizo el master desde el proyecto original del portal $ git checkout jira-XXXX $ git merge master # Actualizo mi rama desde master $ git push origin jira-XXXX # Subo mis cambios Desde Gitlab hago un merge request desde mi rama al master del remote |