¿Qué aprenderá?

Al finalizar este tutorial el estudiante estará en capacidad de usar un flujo de trabajo en Git.

¿Qué necesita?

Para realizar este taller Ud. debe:

1. Tener una conexión a internet

Ramas

Para el flujo de trabajo de Git se usarán las siguientes ramas. :

• main como rama principal del proyecto. Contiene el código de producción que será usado en las herramientas Jenkins, SonarQube y GitInspector. 

• feature serán las ramas sobre las que los desarrolladores trabajarán normalmente. Llevan por defecto el prefijo feature/ seguido del nombre de la rama (ej: feature/implementBookEntity). Nacen desde la rama main y mueren cuando son fusionadas.

• bugfix serán las ramas en las que los desarrolladores corregirán los posibles errores. Llevan por defecto el prefijo bugfix/ seguido del nombre del feature en el cual está el error (ej: bugfix/implementBookEntity). Nacen desde la rama main y mueren cuando son fusionadas.

Creación de la rama feature

Cada integrante clonará el repositorio y creará una rama para su feature así:

git clone URL_DEL_PROYECTO

cd PROYECTO

git checkout -b feature/prueba

Cada integrante, cuando haya realizado los cambios en el proyecto, agregará los nuevos archivos y hará un commit y un push a la rama de su feature así:

git add .

git commit -m “Add entities and repositories”

git push origin feature/prueba

Creación del Pull request (feature - main)

Cada integrante después de haber subido los cambios a la rama de feature irá a la página de GitHub, se ubicará en el repositorio y en el menú Pull requests hará clic en el botón New pull request:

Luego, seleccionará como base la rama main y como compare la rama de la feature o del bugfix y hará click en Create pull request:

Aprobación del Pull Request

Un integrante diferente del que creó el Pull Request deberá revisarlo y aprobarlo o rechazarlo según sea el caso. 

Para aprobar el Pull Request el integrante encargado de la revisión deberá ubicarse en la rama maestra, y mezclar (merge) los cambios con la rama de la feature.

git checkout main

git merge origin feature/prueba

El encargado de la aprobación deberá abril el proyecto y verificar que se cumplan las reglas que se hayan definido. Si todo se cumple, puede subir los cambios con el siguiente comando:

git push

Rechazo del Pull Request

En caso de que las reglas no se cumplan el PR se deberá rechazar (cerrar) y se indicarán las observaciones en la sección de comentarios.

La persona que solicitó el PR deberá hacer los cambios solicitados por el revisor y crear un nuevo PR. 

Tomar los cambios de main

Una vez integrados los cambios en main, todos los integrantes deben ejecutar el siguiente comando para volver a main y tomar los nuevos cambios:

git checkout main

git pull origin main

A partir de este punto se pueden crear nuevas ramas para otros features.