Introduccion a GitFlow

Charla introductoria al workflow GitFlow.

Transcript

1. { INTRODUCCION A GITFLOW Jose Antonio Adame Fernández CETA-CIEMAT 2014
2. INDICE - INTRODUCCION A GIT - TIPOS DE WORKFLOW - GITFLOW WORKFLOW - RAMAS DE FUNCIONALIDAD - CICLO DE PUBLICACION - RAMAS DE MANTENIMIENTO - EJEMPLO
3. INTRODUCCION A GIT - Software de control de versiones diseñado por Linus Torvalds. - Gestión eficiente de proyectos grandes - Distribuido : Repositorios locales y remotos. - Control de integridad. - Facilita la integración de workflows no lineales. - Comandos básicos de Git: - git fetch: Descarga los cambios realizados en el repositorio remoto. - git merge <nombre_rama>: Fusiona en la rama en la que te encuentras trabajando, los cambios realizados en la rama “nombre_rama”. - git pull: Unifica los comandos fetch y merge en un único comando. - git commit -am “<mensaje>”: Confirma los cambios realizados. El “mensaje” generalmente se usa para asociar al commit una breve descripción de los cambios realizados. - git push origin <nombre_rama>: Sube la rama “nombre_rama” al servidor remoto. - git status: Muestra el estado actual de la rama, como los cambios que hay sin commitear.
4. TIPOS DE WORKFLOW: - Centralizado - Usa un repositorio central que sirve como punto de entrada único para todos lo cambios del proyecto
5. - Feature Branch - Todo el desarrollo de funcionalidades debe darse en una rama especializada en vez de en la rama master
6. - Workflow Gitflow - En vez de una única rama principal, este flujo de trabajo utiliza dos ramas para registrar el historial del proyecto.
7. - Workflow bifurcado - En vez de usar un repositorio único central , le da a todos los desarrolladores un repositorio del lado del servidor.
8. - Pull Requests - Son un mecanismo para que el desarrollador pueda notificar a los miembros del equipo de que ha finalizado una funcionalidad y esta sea fusionada en el repositorio central
9. GITFLOW WORKFLOW
10. CARACTERISTICAS: - Estricto modelo de ramas. - Repositorio central. - Los miembros del equipo trabajan de forma local y envían las ramas al repositorio central. - Dos ramas: - Rama master: guarda el histórico oficial de publicaciones - Rama develop: sirve como rama de integración para las funcionalidades.
11. RAMAS DE FUNCIONALIDAD Para cada nueva funcionalidad que se desee añadir al proyecto se creará una rama a partir de la rama develop. Cuando se termina de implementar esta funcionalidad se fusiona de nuevo con la rama develop.
12. CICLO DE PUBLICACION Cada vez que se quiera lanzar una publicación de la aplicación se crea una rama para este propósito llamada release/versión. Acciones a realizar sobre esta rama: - Preparación y revisión del código para su publicación. - Actualización de la documentación. - Otras tareas destinadas a la publicación, como pueden ser errores críticos encontrados. Una vez que esta lista la publicación la rama release/versión se fusiona con la rama master y se etiqueta con un número de versión. Además se vuelve a fusionar con la rama develop que puede haber avanzado desde el inicio de la publicación.
13. RAMAS DE MANTENIMIENTO - Ramas específicas para crear parches de las publicaciones en producción. - Se bifurcan desde master. - Cuando se termina el parche se deberían de fusionar con la rama master y la rama develop.
14. EJEMPLO ESCENARIO DE TRABAJO - Ultima versión publicada 0.1 - Dos desarrolladores: Cesar y Jose - Dos nuevas funcionalidades nuevas a desarrollar.
15. CREACION RAMAS DE TRABAJO Si las ramas de desarrollo y master no estuviesen creadas: git branch origin develop git push origin develop Para que los otros miembros comiencen a trabajar en el proyecto deben de clonar el repositorio del mismo y empezar a trabajar con la rama develop. Git clone url-repositorio git checkout -b develop origin/develop git branch origin master git push origin master
16. DESARROLLO DE NUEVAS FUNCIONALIDADES - Se creara una rama para cada nueva funcionalidad - Nomenclatura de la rama: feature/código-descripcion Las ramas de funcionalidad se crean a partir de la rama develop Cesar y Jose empiezan a trabajar en sus Nuevas funcionalidades: - Cesar crea su rama para su funcionalidad $ git checkout -b feature/aloe-300-fixmessage develop - Jose crea su rama para su nueva funcionalidad $ git checkout -b feature/aloe-331-fixhtml develop Feature/aloe-330- fixmessage Feature/aloe-331- fixhtml
17. MERGE DE LAS RAMAS DE FUNCIONALIDAD Ambos desarrolladores terminan de implementar sus funcionalidades. Hay que realizar el merge con la rama develop. Cesar hace el merge de su rama: $ git checkout develop Switched to branch 'develop‘ $ git pull $ git merge --no-ff feature-fixmessage Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d feature-fixmessage Deleted branch feature-fixmessage (was 05e9557). $ git push origin develop Jose hace el merge de su rama: $ git checkout develop Switched to branch 'develop‘ $ git pull $ git merge --no-ff feature-fixhtml Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d feature-fixhtml Deleted branch feature-fixhtml (was 05e9557). $ git push origin develop
18. PREPARACION DE UNA RELEASE - Petición de publicación nueva versión de la aplicación. - Mientras parte del equipo puede dedicarse a desarrollar nuevas funcionalidades, otra parte puede dedicarse a preparar la release. - Se crea una nueva rama cuya nomenclatura será release/versión. (versión = numero de versión que se va a publicar). git checkout -b release/0.2 develop Tareas a realizar sobre esta rama: - Modificar la documentación - Establecer versiones - Preparativos y pruebas de cara a la publicación. - Corrección de errores críticos encontrados. Cualquier funcionalidad que no este en el rama develop a la hora de crear esta rama se pospone hasta la siguiente publicación develop release/0.2
19. MERGE CON LA RAMA MASTER Se realiza la fusión con la rama master una vez dado el visto bueno a la release para su publicación. Cesar ejecutaría: $ git checkout master Switched to branch 'master' $ git merge --no-ff release-0.2 Merge made by recursive. (Summary of changes) $ git tag -a 0.2 $ git push origin master $ git checkout develop Switched to branch 'develop' $ git merge --no-ff release-0.2 Merge made by recursive. (Summary of changes) $ git push origin develop $ git branch -d release-0.2 master develop
20. RAMAS DE MANTENIMIENTO Si quisiéramos incorporar algún tipo de hotfix a alguna de las versiones publicadas Tendremos que crear una rama de mantenimiento desde la rama MASTER. Esta rama de mantenimiento se fusiona con la rama master y se etiqueta. También se fusiona con la rama develop. $ git checkout -b hotfix/aloe-200-lesioninvalid master # Soluciona el bug $ git checkout master $ git merge hotfix/aloe-200-lesioninvalid $ git push $ git checkout develop $ git pull $ git merge hotfix/aloe-200-lesioninvalid $ git push $ git branch –D hotfix/aloe-200-lesioninvalid master hotfix/código-descripción
21. HERRAMIENTAS Existen algunas herramientas que nos pueden facilitar la tarea a la hora de integrar Gitflow en nuestro entorno de trabajo. - Git-flow : Conjunto de extensiones que nos ahorran trabajo a la hora de ejecutar los comandos anteriormente vistos. - Iniciar el repositorio: $ git flow init [-d] - Gestión de ramas de funcionalidad: $ git flow feature $ git flow feature start <name> [<base>] $ git flow feature finish <name> - Gestión de releases $ git flow release $ git flow release start <release> [<base>] $ git flow release finish <release> - Gestion de hotfixes $ git flow hotfix $ git flow hotfix start <release> [<base>] $ git flow hotfix finish <release>
22. BENEFICIOS DEL USO DE GITFLOW - Agilidad a la hora de desarrollar proyectos - Identificación clara de cada una de las funcionalidades desarrolladas. - Favorece el trabajo y la colaboración entre las personas del equipo. - Correcto control de la línea de trabajo en la rama develop y de las versiones publicadas en la rama master.
23. GITFLOW E INTEGRACION CONTINUA La integración continua puede mejor mucho la metodología Gitflow configurando tareas automáticas en un servidor con Jenkins. - Merges automáticos con la rama develop. - Compilación del código y notificaciones de errores en cada actualización de ramas remotas. - Impide que se suba “código basura” a la rama develop. - Despliegues automáticos de la aplicación. Buenas practicas: - Actualizaciones frecuentes de las ramas remotas permitiendo detección de conflictos de forma prematura. - Inclusión de métricas para verificar la calidad el código. - Ejecución de los tests en cada actualización de las ramas remotas.
24. AGRADECIMIENTOS joseantonio.adame@externos.ciemat.es uaa@ceta-ciemat.es
25. !MUCHAS GRACIAS! ¿DUDAS?
26. REFERENCIAS - ATLASSIAN ( https://www.atlassian.com/es/git/workflows#!workflow- gitflow ) - GIT (http://git-scm.com) - Try GitHub (https://try.github.io/levels/1/challenges/1) - Git-Flow (https://github.com/nvie/gitflow)