Retomamos la herramienta de control de versiones Git con Alberto Casero, Instructor de KeepCoding, experto en desarrollo inteligente y autor del post sobre Django.
Ya hemos comentado la importancia de incorporar Git al trabajo cotidiano, y esta vez Alberto muestra ejemplos concretos del poder de esta herramienta para optimizar tu desarrollo.
Más que control de versiones
Git es una herramienta fascinante. Tras «abrir la lata» y entender su base de funcionamiento es cuando descubres la enorme cantidad de usos que puedes darle más allá del simple control de versiones: mantenimiento de librerías, reutilización de código, construcción de librerías en base a su desarrollo sobre ellas, colaboración en equipos, participación en proyectos open source, entre otros.
Vamos a hacer una breve visita por algunos de los workflows de Git que podemos usar para hacer nuestro día a día más productivo.
El imprescindible: Feature Branch Workflow
Para mí es el workflow imprescindible en Git ya que puedes usarlo tanto en proyectos en solitario como en proyectos en equipo, así como conjuntamente con otros workflows. La base de este workflow es que para cada funcionalidad que vayamos a desarrollar, creemos una rama.
Imaginemos el siguiente escenario: acabo de publicar la primera versión de mi app en App Store/Google Play y he comenzado a trabajar en las nuevas funcionalidades de la siguiente versión. A mitad de camino, me empiezan a llegar los primeros informes de usuariosindicando que hay un bug que causa que se cierre la aplicación.
Sin usar un sistema de control de versiones, tendría dos opciones: corregir el bug cuando termine la funcionalidad o bien deshacer todo el código de la futura nueva versión para descubrir donde estaba el código para publicar una actualización rápida.
Usando el Feature Branch Workflow, para desarrollar la nueva versión habríamos creado una rama a partir del código de la primera versión publicada en las Stores, lo cual me permitiría volver a la rama de la primera versión sin perder el trabajo que ya llevo realizado, corregir el bug, subir una actualziación a las Stores y luego incorporar la solución del bug al código de la segunda versión en el que estaba trabajando.
Fork & Pull Request Workflow
Este workflow es, en gran parte, famoso gracias a Github. ¿Quién no ha visto un botón de «Fork me on Github»?
Este workflow se basa en que cada desarrollador crea una copia (fork) del repositorio original (ojo, no hace una clonación) creando un nuevo repositorio bajo su cuenta de Github (o similar) de manera que el repositorio original y el fork quedan enlazados virtualmente de manera que el fork puede realizar pull requests al repositorio original para incorporar código al original.
Un pull request es una solicitud que recibirá el propietario del repositorio original en la que podrá valorar la incorporación de código desde un tercero (pueden también usarse para hacer code review). Este workflow es clave para favorecer la participación de la comunidad en proyectos open source, permitiendo al manager del proyecto tener un control sobre el mismo (ya que puede decidir si admitir o no un pull request de terceros).
También es un workflow bastante útil para mantener una librería principal que utilizamos en nuestros desarrollos y que vamos haciendo crecer a medida que la utilizamos en diferentes proyectos (incorporando nuevas funcionalidades o parcheando bugs mediante pull requests).
El profesional: Gitflow
Gitflow es un workflow avanzado utilizado en muchos equipos de trabajo que ya tienen experiencia con Git debido a su complejidad.
La idea básica de Gitflow es que existen dos ramas principales en el repositorio central:master y develop.
master es la rama principal o de producción y develop es la rama que se utiliza para integrar las diferentes feature desarrolladas por el equipo. A partir de estas dos ramas principales,pueden surgir tres tipos de ramas (llamadas topic-branches por su «corta vida») locales:
- Ramas feature que se crean a partir de develop y en las que se utiliza nuestro ya conocido feature branch workflow y se unen también a la rama develop.
- Ramas hotfix que se crean a partir de master y se utilizan para apagar fuegos, es decir, arreglas bugs de aplicaciones en producción. Estas ramas se acaban uniendo con master ydevelop a la vez para aplicar así el parche tanto a la versión de producción como a la de desarrollo.
- Ramas release utilizadas para integración y configuración de releases previas a su despliegue en producción. Este tipo de ramas se crean a partir de la rama develop y se unen tanto con master como con develop.
Para poder utilizar Gitflow hay que tener un disciplinado equipo que entienda perfectamente el funcionamiento de Git. Aunque gracias a herramientas gráficas como Sourcetree el utilizar Gitflow para los rookies en Git es una tarea bastante sencilla.
Ni estos son los únicos y puede que no todos los usemos de la misma manera, pero de lo que no hay duda es que Git es más que un sistema de control de versiones: una gran herramienta para nosotros, developers.
Prueba todas las posibilidades a partir de estos tres escenarios, y destaca del resto con un código limpio y una dinámica de trabajo eficiente. Recuerda que no sólo se trata de picar código, sino de dominar las herramientas. Descubre esto y más en el KeepCoding Startup Engineering Master Bootcamp.
