¿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

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

• master 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 master 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 master y mueren cuando son fusionadas.

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

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 master y como compare la rama de la feature o del bugfix y hará click en Create 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 master
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

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.

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

git checkout master
git pull origin master

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