Mercurial vs 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.

Para Mercurial, el sitio de referencia es BitBucket, a diferencia de GitHub cuenta con soporte
tanto para Mercurial como para Git. Sus funcionalidades son similares a las de GitHub aunque
la moda haga que este último tenga más seguidores. Sin embargo su plan de precios es
diferente al de GitHub ya que BitBucket cobra por número de colaboradores de manera que
por debajo de 5 colaboradores nos permite tener todos los repositorios que queramos de
manera gratuita, tanto públicos como privados. Eso lo hace especialmente interesante para
desarrolladores que hagan muchos proyectos en solitario. Algunos proyectos famosos que
hacen uso de BitBucket son PyPi o Sphinx (ver artículo anterior).

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).