Angular+gitlab+git

Como crear ramas virtuales de tus cambios desde un ISSUE en Gitlab.

Franco Bello Díaz
6 min readMay 21, 2020

Como pre-requisito para este tutorial debes tener creado un proyecto angular, si no tienes uno, te dejo el LINK de otro tutorial que tengo en donde explico paso a paso como crear uno, también tener instalado GIT.

Cuando estamos en una célula de trabajo, generalmente tenemos a alguien llamado GITMASTER que tiene como misión hacer todos los pasos y mantener un orden en las versiones gestionando los merge request de cada desarrollador, y documentando los cambios para tener una buena entrega, acá te dejo un instructivo de como crear ramas virtuales en base a un issue.

Primero que nada nos vamos al GITLAB y creamos un repositorio.

crear repo gitlab

Apenas tengamos creado el repositorio, nos vamos a nuestra consola de preferencia y realizamos la subida del proyecto angular que hemos creado con anterioridad, tenemos que ejecutar estos comandos git para empezar.

1- git config --global user.name "tu-nombre"
2- git config --global user.email "correo@nn.com"
3- git init
4- git remote add origin https://gitlab.com/user/rama.git
5- git add .
6- git commit -m "COMMIT Inicial"
7- git push origin master

Con el comando git push origin master, subiremos el proyecto al repositorio.

git push de mi proyecto

1- Crear un ISSUE

Luego de esto, nos vamos al gitlab en el sidebar lateral izquierdo seleccionamos la opción Issue -> List y presionamos New Issue.

issue

Luego ingresamos los siguientes datos:

issue ingresar datos

Titulo: Un titulo claro y conciso.

Descripción: Tiene que ser una descripción muy clara de que es lo que se tiene que hacer.

Asignar: A quien se lo asignaremos, generalmente esta tarea viene de un desarrollador, tiene que ser asignada al GIT MASTER (persona encargada del repositorio y de hacer los pases).

Milestone: Esta opción nos permite agregar la tarea a los SPRINT creados con anterioridad, como pueden apreciar, GITLAB puede manejar temas de AGILIDAD por lo tanto nos crea una tabla de tareas para ir moviendolas y gestionando sus avances.

2- Crear un merge request

Cuando ya tenemos creado el issue, GITLAB nos mostrara la información de la siguiente manera:

Como indica la imagen tenemos las siguientes opciones:

Create mergue request: Es una solicitud de fusión a partir de un issue también nos da a elegir desde que rama queremos crearla. Una vez creado el issue, gitlab entrega un identificador único para el proyecto el cual nos ayudará a realizar el seguimiento correspondiente. Es importante destacar que esta acción generará la rama de forma virtual en gitlab, no en los equipos locales. El nombre de esta rama esta construida entre la concatenación del identificador del issue + el nombre del issue. Adicionalmente en la opción Source (branch or tag) se indica desde que rama se creará, recomendando siempre la rama por defecto. Es en este punto donde se debe poner atención ya que aquí se establece si es un cambio de desarrollo (develop) o de producción (master/tag).

Una vez creada la solicitud de merge este queda vinculado al issue, se debe asignar a quien estará encargado de revisar y aceptar los cambios realizados. Si no se realiza este paso, se creará la solicitud pero la persona encargada de revisar nunca podrá ver los cambios.

merge request

Acá podemos ver el issue ya creado con el WIP (Working in progress) listo para recibir cambios. También como indicábamos mas arriba gitlab nos entrega un ID que sera el que cerraremos mas tarde.

3.- Obtener rama creada a partir de un issue.

Como se mencionó anteriormente las ramas son creadas virtualmente en gitlab, así que para poder obtenerlas y trabajar en ella se deben ejecutar los siguientes comandos GIT en nuestro equipo local:

git fetch origin: Obtiene todas las referencias que están en gitlab.

git fetch

git checkout {nombre-de-la-rama}: Salimos de la rama actual y nos metemos a la rama creada en gitlab.

git checkout

Al ejecutar estos pasos y abrir nuestro proyecto en nuestro IDE favorito, se detectara automáticamente la rama virtual creada en GITLAB.

visual code

Luego que terminamos de trabajar en nuestra rama virtual agregando todos los cambios necesarios para terminar la tarea, nos vamos a la consola y ejecutamos los siguientes comandos GIT.

git add: Este comando nos permite añadir todos los archivos para el commit.

git add

git commit -m “texto del commit”: Este comando nos permite hacer el primer commit.

git commit

git push origin { rama virtual }: Este comando nos permite subir todos los cambios a nuestra rama virtual para que este disponible en ORIGIN (repo) y listos para hacer MERGE.

git push

Apenas hacemos el push nos dirigimos a gitlab y si nos fijamos bien este hizo el push de forma correcta y nos habilita un botón que se llama RESOLVE WIP STATUS esta acción nos permite resolver el woking in progress, esta tarea la tiene que hacer el desarrollador siempre y cuando este listo para subir y hacer merge a master, apenas lo haga le llegara la solicitud al responsable que en este caso es el GIT MASTER o la persona que esta a cargo de los repositorios y de hacer los pases. A el le llegara una solicitud de merge y se le habilitara el botón MERGE.

resolve wip

Como en este caso el responsable soy yo, se me habilita el botón MERGE y abajo me aparece que el desarrollador realizo las acciones disponibles.

Presionamos el botón y todos los cambios se unirán a la rama MASTER.

merge wip

Finalmente el issue queda en estado RESOLVE y automáticamente se cierra la tarea.

Como ultimo paso, nos vamos de nuevo a nuestra consola y ejecutamos los siguientes comandos para dejar nuestra rama actual lista para otro issue:

git checkout master: Este comando nos cambia a la rama master.

git checkout

git pull origin master: Este comando nos trae todos los cambios que se agregaron a la rama master, la idea es siempre tener la ultima versión.

git pull origin master
Gracias!

Muchas gracias por llegar hasta acá y muy agradecido que le pongas “CLAPS” a mis publicaciones, y claro se agradecen todos los feedback posibles, así podre ayudar a los demás de la mejor manera posible.

--

--

Franco Bello Díaz

Arquitecto Frontend // Angular | Microfrontend | TS | CI-CD | Jenkins | Docker | Gitlab | Gitflow | Jira | Azure | Kanban | Oracle