Sistemas de control de versiones hay muchos y muy variados: CVS, Subversion, Darcs, StarTeam, etc. Son herramientas muy valiosas, tanto que ningún programador puede omitirlas. En la siguiente nota voy a comentar algunos hábitos que he observado en la gente que las utiliza:
No utilices el control de versiones como si fuera un backup
Este es uno de los mayores errores a la hora de utilizar estas herramientas. Frecuentemente oigo la frase: ¿has puesto a salvo tu código en el repositorio?. ¡Mal! Almacenar el código en un repositorio no es sinónimo de seguridad, la seguridad la proporciona una copia de respaldo de ese código, no el repositorio en sí.
Tomaremos como ejemplo Darcs, un sistema de control de versiones no muy conocido. Este soft funciona en local, como un proceso más, sin necesidad de centralizar el control en un servidor como ocurre con otros sistemas como CVS o Subversion. En este caso, un fallo de disco podría echar a perder tu trabajo; por esta razón debes hacer copias de seguridad, el sistema de control de versiones no tiene nada que hacer ante este tipo de contingentes.
Los desarrolladores que utilizan el control de versiones con el rol de sistema de backup frecuentemente hacen un commit de su trabajo al día, por ejemplo cuando termina su jornada laboral, como una forma de respaldo diario. Esta no es una práctica aceptable, especialmente si formas parte de un equipo de desarrollo. Imagina que sólo actualizas tu proyecto por la mañana, cuando empieza tu jornada, y remites los cambios al finalizarla. Cada mañana perderás mucho tiempo únicamente lidiando con todos los cambios que enviaron tus compañeros el día anterior y que entran en conflicto con los que tu hiciste. No es una práctica muy inteligente, ¿no crees?
Remite los cambios tan pronto como conformen una unidad lógica
¿Cada cuanto debo remitir los cambios?. Hay que llegar a un término medio: no remitas cada línea que escribes ni lo hagas después de todo el día trabajando. Debes hacer un commit tan pronto como los cambios conformen una unidad lógica, por ejemplo cada vez que un conjunto de cambios tengan sentido.
Estas unidades lógicas responden en la mayoría de los casos a tu plan de desarrollo: encuentras un bug en la rama de desarrollo actual, planeas una estrategia para solucionarlo, lo arreglas y ahí tienes tu unidad lógica: envía los cambios al repositorio. El commit cobra sentido porque soluciona un bug específico; la versión X tiene un bug y la versión X+1 ya no.
No tengas miedo de remitir pequeños cambios con mucha frecuencia, nadie se enfadará porque seas conciso solucionando cosas pequeñas. Considera la situación extrema en la que, después de meses de desarrollo, necesitas recordar cuál fue la revisión en la que se solucionó aquella falta de ortografía en una cadena de depuración. Si utilizaste correctamente el patrón de "una solución, un envío" no tienes más que investigar la lista de envíos para descubrir cuál de ellos estas buscando.
Frecuentemente ocurre que estás trabajando en una "unidad lógica" cuando descubres que hay un error en otra parte del código y lo corriges, y envías la corrección junto con tus cambios todo dentro de un mismo commit haciendo que esta corrección pierda visibilidad. Esto debe evitarse en la medida de lo posible.
