A pesar de lo evidente que resulta el control de versiones en un desarrollo de software, he visto muchos casos de empresas en los que no se hace o no se hace de forma correcta. En muchos casos, por atender temas “urgentes”, se empiezan a hacer cambios directamente en ambientes productivos y luego ya se pierde el control del código.
Hoy les quiero hablar de Git, Github y un flujo de trabajo que, a pesar de ser sencillo, puede facilitar mucho el trabajo de un equipo que no esté llevando un control de versiones. El flujo de trabajo del que les voy a hablar se denomina Ramas puntuales (o Topic branch -> https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Flujos-de-Trabajo-Ramificados#r_topic_branch), y se basa en la creación de ramas o branches para crear una nueva funcionalidad, corregir un bug, aplicar una mejora, etc.
Considerando que se tenga una rama productiva master, a continuación, creamos una nueva rama para una nueva funcionalidad:
git checkout -b feature/nueva_funcionalidad
Con esto, crearemos la nueva rama feature/nueva_funcionalidad donde se programará lo que se requiera para cumplir con el requerimiento.
Se identifican los archivos que fueron modificados:
git status
Este comando es muy importante porque muestra los archivos modificados, los archivos nuevos que aún no están versionados y los archivos preparados para confirmar y enviar al repositorio local.
Posteriormente, se agregan los archivos con cambios al Stage para prepararlos para el siguiente paso:
git add <archivo_1> <archivo_2> … <archivo_n>
Una vez que los archivos están en el área de Stage, se deben confirmar para guardar los cambios en el repositorio local:
git commit -m “Nueva funcionalidad que resuelve…”
Con los cambios confirmados, se hace push de la rama al repositorio remoto, especificando el nombre de la rama local y como se va a llamar en el repositorio remoto:
git push origin feature/nueva_funcionalidad:feature/nueva_funcionalidad
De acuerdo a cómo esté organizado el equipo de desarrollo, la persona o personas encargadas proceden a revisar el código de la nueva funcionalidad, hacer un Pull request para hacer el merge con la rama master y actualizar el ambiente productivo. Cabe destacar que el Pull request lo puede solicitar el desarrollador de la funcionalidad o el encargado de revisar la nueva rama, pudiendo rechazarse la solicitud si no cumple con las espectativas (ver Flujo de trabajo Administrador – Integración -> https://git-scm.com/book/es/v2/ch00/rwfdiag_b).
Una vez que el cambio esté en master, en el ambiente local se regresa a la rama master y se hace pull para incoporar los cambios de la rama que tiene la nueva funcionalidad a la master (local).
git checkout master
Este flujo de trabajo tiene ventajas importantes a considerar:
1. Se controla y valida cada liberación a la rama master o productiva.
2. Se revisa el código por uno o más integrantes del equipo, contribuyendo al aseguramiento de calidad y cumplimiento de lineamientos, convenciones y buenas prácticas.
3. Se genera documentación de las liberaciones de nuevas funcionalidades, corrección de bugs, etc.
4. Se genera retroalimentación sobre las técnicas utilizadas por cada miembro del equipo, fomentando la mejora continua.
Hay diversos flujos y variantes para trabajar con Git por lo que hay que escoger la forma que mejor se ajuste al equipo y a las frecuencias de entrega de funcionalidades que espera la gerencia o dirección de desarrollo.
También puedes verlo en: https://www.linkedin.com/pulse/git-un-flujo-de-trabajo-paso-juan-francisco-yendy-henr%25C3%25ADquez
Comentarios recientes