Tutorial flujo de trabajo en Git

¿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 y SonarQube. 

• develop como rama intermedia del proyecto. Contiene el código que se probará antes de integrar a main. 

• 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 en develop.

• 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 - develop)

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 develop 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 develop, y mezclar (merge) los cambios con la rama de la feature.

git checkout develop

git merge origin feature/prueba

El encargado de la aprobación deberá abril el proyecto y verificar que todo se ejecute correctamente. 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 develop

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

git checkout develop

git pull origin develop

Posteriormente, y siguiendo los mismos pasos, se podrán integrar los cambios de develop a la rama main.

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