Empecé examinando las opciones existentes. No quería casarme con ninguna opción sino decidir cual era más apropiada para aprender a usar una herramienta de control de versiones, sin perjuicio de utilizar otras en el futuro si surge la necesidad.
Aunque en entornos corporativos he visto que se utiliza Subversión, opté por investigar otras opciones más populares entre desarrolladores independientes. Launchpad, la infraestructura montada por Canonical para albergar proyectos de software libre usa Bazaar, pero leí críticas negativas respecto a él sobre que se estaba quedando anticuado y en general me pareció demasiado ligado a proyectos enfocados a Ubuntu. Como mis proyectos no necesariamente se enfocan a Ubuntu decidí descartar, por ahora Bazaar. Las dos opciones siguientes eran Mercurial y Git.
Elegir entre Mercurial y Git no es fácil. Internet está llena de debates en los que se discute cual de los dos es mejor. La verdad es que hay tantos argumentos a favor tanto de uno como de otro que la conclusión final es que los dos son herramientas muy potentes que conviene conocer dado que según la situación nos puede convenir utilizar una u otra. En realidad su origen es muy similar, hace algún tiempo el grupo de trabajo que desarrolla el kernel de Linux decidió escribir su propia herramienta de control de versiones. Se abrieron dos vías de desarrollo, una capitaneada por el mismo Linus Torvals que desarrolló Git usando C, Bash y Perl (en el pecado llevarán la penitencia), la otra la lideraba Matt Mackall que desarrolló Mercurial usando C y Python. Al final se optó por Git en parte porque se finalizó unos días antes y en parte, dicen las malas lenguas, por ser obra de Linus.
En un blog bastante divertido encontré una analogía que aunque fue escrita en 2008 parece que sigue siendo aplicable a la actualidad: Git es como MacGyver mientras que Mercurial es como James Bond.
Antes de que a alguien le de un shock vamos a explicarlo. Git parte del enfoque de Unix de que cada tarea concreta se haga con un ejecutable particular, de manera que las tareas más complejas se realicen combinando los ejecutables individuales. Como consecuencia de ellos instalar Git supone la instalación de más de 100 programitas especializados en tareas concretas del control de versiones. Esto eleva la dificultad de aprender Git pero aumenta exponencialmente su flexibilidad permitiendo que pueda ser configurado para dar soporte a los workflows de desarrollo más complejos que se nos puedan ocurrir. Ese enfoque de combinar elementos sencillos para dar lugar a sistemas más potentes es lo que hace de Git el MacGyver de las herramientas de control de versión. Como ya hemos dicho, un proyecto que está haciendo uso activo de Git en su desarrollo es el del kernel de Linux.
Mercurial es sin embargo mucho más sencillo. Sólo instala un ejecutable el cual se usa en cada situación con unos argumentos u otros. Esta sencillez facilita enormemente su aprendizaje y de hecho, se dice que los que conocen Subversion encuentran realmente fácil pasar a Mercurial porque los comandos principales son muy parecidos. Hay que reconocer que en Mercurial todo es bastante intuitivo y limpio. Al final, el 80% del tiempo uno acaba usando siempre unos pocos comandos nada más. Frente a la flexibilidad de Git, Mercurial ofrece sencillez. Por eso, Mercurial es como James Bond, si lo utilizas en la situación correcta será capaz de solucionarla de manera espectacularmente elegante y aún te sobrará tiempo para tomarte un martini con vodka ;-). Sin embargo, esa sencillez no significa que Mercurial carezca de potencia, grandes proyectos de la comunidad libre lo utilizan, como el que desarrolla el mismo Python o varios de la fundación Mozilla. En realidad, por alguna razón la tendencia general es que los desarrolladores de Python prefieren Mercurial, quizás porque está más cerca del Zen de Python cuando dice: "Simple is better than complex"
Si uno trabaja en un proyecto donde el modelo de desarrollo es complejo porque implica a mucha gente y muchos frentes de trabajo quizás lo lógico sería elegir Git. Sin embargo, si la organización del desarrollo de nuestro proyecto es sencilla lo más seguro es que Mercurial nos permita avanzar de manera más rápida y efectiva.
Otro elemento a valorar es el soporte que se le da a cada herramienta de control de versiones a la hora de subir a la nube nuestros repositorios para facilitar el trabajo colaborativo. En el caso de Bazaar, el lugar emblemático para colgar proyectos es el mencionado Launchpad, pero ya hemos dicho que este se centra en el desarrollo para Ubuntu.
Para Git, el sitio más famoso donde colgar nuestro repositorio es GitHub, el cual cuenta con una tremenda popularidad dadas las interesantes posibilidades sociales que le han dado al portal, de manera que resulta muy fácil compartir código con otras personas. Su plan de precios cobra por repositorios privados de manera que hasta 5 repositorios privados deberemos pagar hasta 7$ al més. Sin embargo, podemos tener todos los repositorios públicos que tengamos sin límite de colaboradores (personas con acceso de escritura sobre el repositorio). Esto hace que proyectos como Django, hayan elegido GitHub como su repositorio público.
Por lo que he podido ver por ahí, muchos desarrolladores reconocen usar ambos portales: tienen sus desarrollos privados en BitBucket y cuando quieren hacer público uno y abrirlo a la colaboración de la comunidad recurren a GitHub.
En mi caso concreto, mis desarrollos son pequeños y privados por lo que empezaré usando Mercurial y BitBucket. Con eso podré familiarizarme con los procedimientos típicos del control de versiones. Y en el futuro ya veremos si me merece la pena aprender Git (y GitHub).
