Que le pido a un control de versiones: favorecer comits atómicos

Todos hacemos comits constantemente en nuestros sistemas de control de versiones. Una de las características que valoro en estas herramientas es la facilidad que den para hacer comits atómicos.

En decir, cuando tienes un cambio que afecta a muchos ficheros, muchas veces se cae en la tentación de ir revisando cada fichero para ir seleccionando cual hay que comitear y cual no, pero comiteando cada fichero revisado, en vez de todos juntos.

Aunque obviamente tienes todos los cambios en el control de versiones, no tienes todos agrupados, porque has ido haciendo varios commits, según revisabas.

Esto hace que si quieres llevarte el cambio a otro sitio o sacarlo de una versión sea más difícil con varios commits que con uno único.

De los controles de versiones con los que he trabajado, solo hay dos que facilitan estos commits atómicos, y son el Git y el Rational Team Concert.

Ni el Visual Source Safe, ni el CVS, ni el Subversión lo hacen.

Que le pido a un control de versiones: suspender trabajos a medias

Inicio con esta entrada una serie de sobre que requisitos creo que debe cumplir un sistema de control de versiones. La intención es hacer entradas cortas reflejando las características que me gustaría tener.

La primera característica es la de poder suspender trabajos. Es decir, mientras estas realizando una tarea poder guardar el estado de tu entorno de trabajo para atender otra tarea más prioritaria, por ejemplo, un error en producción, y una vez solucionado esa tarea prioritaria, poder continuar con la tarea que originalmente estabas realizando.

De los controles de versiones con lo que he trabajado los únicos que lo implementan de forma nativa son el Git y el Rational Team Concert.

El resto de herramientas con las que he trabajado (Visual Source Safe, CVS y Subversion) no lo soportan de forma nativa, así que hay que recurrir a métodos más manuales como comitear los cambios a medias o bien a guardárselo en otra carpeta. Ambas soluciones muy poco elegantes.

Que mal venden el Git

Estoy empezando a usar el repositorio de código Git, como ya comenté en unas entrada de mi proyecto MyCloudChest. Cada día me gusta más, pero tengo que reconocer que me parece que se venden muy mal y me ha costado verle las mejoras que aporta.

Me explico. Si miras por Internet lo primero que te destacan es que es un repositorio de código distribuido, que te permite trabajar, por ejemplo, mientras vas de viaje en un avión y no tienes conexión. 

Me imagino que la gente que escribe eso viajará mucho en avión, pero cuando te lo planteas para tu empresa, pues no se en estados unidos, pero en los sitios en los que yo he trabajado, los programadores están en la oficina en su mesa trabajando con un ordenador de sobremesa, así que de primeras no le ves mayor utilidad y lo descartas.

Por circunstancias, que ya explique, si que me ha sido útil el usar un repositorio de código distribuido, para avanzar en el pueblo en este proyecto personal, porque allí (o más bien aquí que ahora mismo estoy escribiendo esto desde el pueblo) no dispongo de ADSL, solo móvil.

Los viajes en avión no, pero en cambio si hay situaciones que se me han planteado en varias empresas y con varios clientes en las que un repositorio como Git puede ser útil. Muchas empresas te obligan a dejar el código en sus repositorios, normalmente Subversion. Pero claro, no siempre tienes una buena conectividad con esos sitios, ya que suelen darte acceso mediante VPN. Esto te obliga a tener tu repositorio Subversion en tu empresa, para poder trabajar con eficiencia y luego hacer un corta y pega al repositorio del cliente y subirlo mediante la VPN.

Como el Git permite trabajar con varios repositorios «servidores» si puede ser más adecuado que un Subversion.

Esto si me parece una situación más cercana, no como el trabajar desde el avión.

Otra de las cosas que no veo bien explicadas es el uso de la zona de staged, cuando lo ves lo primero que piensas es, vaya rollo, tengo que añadirlo a la zona de staged, luego comitearlo y luego empujarlo. Si en subversion hago un commit y ya está, se me van a liar los programadores y siempre procuro gestionar la capacidad de la gente.

Me dio la pista un vídeo de aprendegit.com

Lo que si que he visto en muchos casos, y he de reconocer que yo también he hecho, es el comitear cambios de una única incidencia en varias veces, porque tienes muchos ficheros modificados y vas revisando uno a uno a ver si es un cambio que tienes que subir o no.

En esta situación si que es claramente interesante el disponer de la zona de staged. Voy revisando los ficheros y decidiendo cual debo subir y cual no, y una vez que los tengo todos revisados los comiteo en bloque.

A esta situación de ejemplos poco realistas, a mi parecer, no ayuda mucho tampoco los clientes gráficos de Git, con Eclipse y su pluggin no he sido capaz de actualizarme unos cambios que tenia en el servidor, me daba un error de que no tenia un branch configurado. Menos mal que ha salido hace no mucho el programa SourceTree que es mucho más intuitivo y con ese funciono mucho mejor.

En resumen, un repositorio de código que tiene muy buena pinta, pero con una entrada bastante dura.

La calidad del código

No deja de sorprenderme el encontrarme con código que da dolor leerlo.

Puedo entenderlo en programas viejos desarrollados cuando no se disponia de herramientas que te ayudasen a mejorarlo.

Pero hoy día con la cantidad de herramientas gratuitas que existen me es muy dificil de entender que mucha gente ni las conozca y lo que es peor, que las conozca y no las use.

Es muy triste que el control de calidad se quede en «compila y funciona».

Algunas herramientas para auditoría y métricas gratuitas como PMD, CheckStyle o Eclipse nos pueden ayudar de una forma muy facil a escribir mejor código con muy poco esfuerzo