GIT VCS: mejorando la productividad con GMASTER y sus capacidades semánticas

He estado utilizando diferentes sistemas de control de versiones desde 2002 (CVS, Subversion, Plastic, GIT y uno propietario), y siempre estoy buscando una oportunidad de mejorar la productividad en nuestro equipo. Estoy convencido de que podemos dar un salto de calidad en mejorar nuestra productividad cuando usamos GIT como sistema de control de versiones, si pasamos de una herramienta de tipo "Text Diff" a una herramienta con "Semantic Diff".

El pasado lunes 30 de noviembre asistimos a una interesante presentación de Pablo Santos hablando del cliente de GIT GMASTER.

En un equipo de desarrollo "Agile", los refactors deben ser considerados operaciones cotidianas, y una herramienta con "Semantic Diff" puede ayudarnos bastante a ahorrar tiempo.

En el video a continuación me gustaría simplemente mostrarte 3 ejemplos acerca del uso de

GMASTER y sus capacidades semánticas.

1) Semantic visual diff.

En el primero, un par de métodos llamados startServer y stopServer han sido movidos ligeramente.
Como podemos ver, con una heramienta diff de tipo texto se percibe el cambio como una operación de borrar y agregar. Por el contrario, es fácil seguir y entender el cambio con GMASTER y sus capacidades semánticas.

2) Criss-cross diff.

En el segundo, vamos a refactorizar el código, movemos un método hacia arriba y otro abajo. Adicionalmente, agregamos comentarios a ambos métodos.
Podemos ver que con una herramienta diff de tipo texto se percibe el cambio como una sucesión de operaciones de borrar y agregar. En cambio con GMASTER y sus capacidades semánticas podemos visualizar fácilmente la relación entre los bloques uno al lado del otro.

3) Semantic merge.

En el último, comparamos operaciones cotidianas, trabajando sobre dos ramas (una rama main y una rama -por tarea- hija), usando dos herramientas diferentes:
a) Una versión obsoleta de Plastic SCM (3.0?), sin capacidades semánticas.
b) Nuestra flamante herramienta GMASTER con capacidades semánticas.

Consta de tres pasos:

  • En la rama main, movemos el método run hacia arriba.
  • En la rama hija (rama por tarea), cambiamos el mismo método.
  • Finalmente, cambiamos a la rama principal de nuevo, e intentamos el merge desde la hija hacia ella. El merge termina con un conflicto.

La diferencia es que mientras con Plastic SCM el conflicto tiene que ser resuelto manualmente, usando GMASTER (debido a sus capacidades semánticas) la herramienta de merge resuelve el conflicto automáticamente.

Por favor, disfruta el video.

Alberto Morales Morales

Software craftsman. Passion for developing quality code that can be proud of. Happily married.

Madrid, Spain.