El señor Joel [1] escribe muchas verdades sobre control de versiones distribuido:

“No puedo decirte cuantos usuarios de Subversion me han contado esta historia:

«Tratamos de hacer un branch de nuestro código, y funcionó bien. Pero cuando llego el tiempo de hacer el merge, fue una pesadilla y prácticamente tuvimos que aplicar cada cambio a mano. Juramos nunca más volverlo a hacer y desarrollamos una nueva manera de desarrollar software utilizando condicionales if’s en lugar de branches»

A veces hasta están un poco orgullosos de esta nueva invención de ellos. Como si fuera una virtud el hecho de que tu control de versiones no esta haciendo lo que esta supuestamente destinado a hacer.”

¿A quién no le ha pasado? hacer merges después de muchos cambios en Subversion es un dolor de cabeza.

Yo solo he trabajado en proyectos personales con Git, pero el hecho de que te permita trabajar sin conexión y hacer commits localmente es oro puro. Pero para equipos tiene aún más ventajas. En serio, el hecho de poder hacer cambios como loco, guardando un historial de ellos sin que temas romper el repositorio de los demás no es apreciado lo suficiente. Agrega a eso branching y merges que funcionen como se supone que deben de funcionar y no hay ninguna razón para que no lo pruebes [2].

Git y Mercurial son a Subversion lo que el mismo fue para CVS. Simplemente son mejores.

[1] Por mucho uno de mis bloggers favoritos, es una verdadera lástima que se retire.
[2] HG Init es una gran guía para entender sistemas de version distribuidos, aunque esta orientado a Mercurial, te servirán los conceptos para Git. learn.github es el imprescindible si estás interesado en Git.