COMANDOS GIT

Objetivo: Realizar el flujo de la estrategia de branching hasta la rama develop.

Precondiciones:

Tener creada la rama sprint-001 / team-001, considerando que debe tener habilitado al menos un revisor
requerido (el Revisor de Código).

Flujo de los comandos de GIT desde el punto de vista del Desarrollador:

1. Clonar repositorio remoto.
 git clone https://coppelretail@dev.azure.com/coppelretail/training.minsait-
sandbox/_git/Coppel-TrainJava-AppCoppel
2. Obtener últimos cambios del repositorio remoto.
 git fetch
3. Integrar los últimos cambios de la rama remota (master).
 git pull
4. Consultar el listado de ramas locales y remotas, se indica la rama actual (Debe estar colocado sobre la rama
sprint-001).
 git branch -a
 En caso de que este sobre otra rama debe cambiarse a la rama sprint-001 / team-001:
 git checkout sprint-001
 git pull
5. Crear rama de característica o historia de usuario.
 git checkout -b feature-caracteristica1
6. Crear rama de trabajo de Task basada en la rama creada anteriormente.
 git checkout -b task-tarea1
7. Hacer cambios en el código (Trabajar sobre la rama creada anteriormente).
8. Una vez terminados los cambios, se deben enviar éstos al stage.
 git add .
9. Hacer commits de los cambios.
 git commit -m “Descripción del cambio”
10. Empujar la rama task-tarea1 y cambios hacia el repositorio remoto.
 git push origin task-tarea1
11. Generar Pull Request de las ramas (origen: task-tarea1 destino: feature-caracteristica1).
 Desde el portal de Azure Devops, generar el Pull Request de la rama task-tarea1 hacia la rama
feature-caracteristica1
 Generar el auto-complete marcado la casilla de eliminar rama.
12. Aplicar el Pull Request de las ramas (origen: task-tarea1 destino: feature-caracteristica1).
 Completar el Pull Request.
i. Los cambios de la rama task-tarea1 se integrarán a la rama feature-caracteristica1
ii. La rama task-tarea1 se eliminará.
iii. Se ejecutará el Pipeline de Inspección Continua.
 NOTA: Mientras el Pull Request no esté aplicado, se puede seguir trabajando en la rama task-tarea1
y enviado cambios a la rama feature-caracteristica1 (es decir, repetir los pasos del 8 al 11).
13. Regresar a la rama (feature-caracteristica1) de característica u historia de usuario:
 git checkout feature-caracteristica1
 git pull
  Si hay más Task por realizar, repetir los pasos del 6 al 14, si no, continuar al paso 15.
14. Generar Pull Request de las ramas (origen: feature-caracteristica1 destino: sprint-001 / team-
001).
 Desde el portal de Azure DevOps, generar el Pull Request de la rama feature-caracteristica1
hacia la rama sprint-001 / team-001
 Generar el auto-complete (No marcar la casilla de eliminar rama).
15. Aplicar el Pull Request de las ramas (origen: feature-caracteristica1 destino: sprint-001 / team-
001).
 Al Revisor de Código le llegará un correo para notificarle que tiene un Pull Reques por aprobar.
 El Revisor de Código evalúa visualmente los cambios enviados por el desarrollador.
 El Revisor de Código es el encargado de evaluar que se haya cumplido la historia de usuario.
 El Revisor de Código puede poner comentarios u observaciones del código desarrollado. (En este caso el
desarrollador debe hacer un fix de código, para eso debe repetir los pasos del 6 al 13).
 El Revisor de Código aprueba el Pull Request.
i. Los cambios de la rama feature-caracteristica1 se integrarán a la rama sprint-001 /
team-001
ii. Se ejecutará el Pipeline de Inspección Continua.
16. Validación del resultado de la Inspección Continua por parte de Revisor de Código.
 El Revisor de Código valida visualmente el resultado de la Compilación, Reporte de SonarQube y Reporte
de Checkmarx que hayan sido pasados o aprobados.
 NOTA: Si no se cumple alguna de estas condiciones previas el desarrollador debe generar un fix de
código, para eso debe repetir los pasos del 6 al 14.
17. El Revisor de Código o Lider Técnico del equipo Genera el Pull Request (con la estrategia de merge de Squas
Commit, esta estrategía es MANDATORIA) hacia la rama develop.
18. El SCM Aprueba el Pull Request
 Los cambios se integran a la rama develop.
 Se ejecuta el Pipeline de Integración Continua.
 Se ejecuta el Pipeline de Entrega Continua (El SCM debe aprobar el despliegue en el ambiente de
Desarrollo).
19. El Desarrollador valida la característica u historia de usuario desarrollada (en el ambiente de Desarrollo).
20. El Desarrollador elimina la rama feature-caracteristica1
 git branch -d feature-caracteristica1
21. Regresar a la rama sprint-001 / team-001
 git checkout sprint-001
 git pull
22. Para iniciar una nueva característica o historia de usuario, repetir los pasos del 5 en adelante.
* Los nombres de las ramas, aunque siguen la nomenclatura de nombrado, solo son ilustrativas.