Siempre me pregunté por qué git prefiere los hashes sobre los números de revisión. Los números de revisión son mucho más claros y fáciles de consultar (en mi opinión): ¡hay una diferencia entre decirle a alguien que eche un vistazo a la revisión 1200 o cometer 92ba93e! (Solo para dar un ejemplo).
Entonces, ¿hay alguna razón para este diseño?
Un solo número de revisión que aumenta monotónicamente solo tiene sentido para un sistema de control de versiones centralizado, donde todas las revisiones fluyen a un solo lugar que puede rastrear y asignar números. Una vez que entras en el mundo DVCS, donde existen numerosas copias del repositorio y se extraen los cambios y se envían a ellos en flujos de trabajo arbitrarios, el concepto simplemente no se aplica. (Por ejemplo, no hay un lugar para asignar números de revisión: si doy un bifurcación a su repositorio y usted decide un año más tarde para retirar mis cambios, ¿cómo puede un sistema garantizar que nuestros números de revisión no entren en conflicto?)
Necesita hashes en un sistema distribuido. Digamos que usted y un colega están trabajando en el mismo repositorio y que ambos realizan un cambio localmente y luego lo empujan. ¿Quién es el número de revisión 1200 y quién es el número de revisión 1201 dado que ninguna de las partes tiene conocimiento sobre la otra? La única solución técnica realista es crear un hash de los cambios utilizando un método conocido y vincular las cosas en función de eso.
Es interesante que HG sea compatible con los números de versión, pero son explícitamente una función solo local: su repositorio tiene un conjunto, el repositorio de su compañero de trabajo tendrá un conjunto diferente dependiendo de cómo empujaron y sacaron. Sin embargo, hace que el uso de la línea de comandos sea un poco más amigable que Git.
Respetuosamente estoy en desacuerdo con las respuestas actuales. Los hash no son necesarios para un DVCS, consulte la forma Bazaar . Podría hacerlo también con cualquier otro tipo de identificador único global. Los hashes son una medida para garantizar la integridad de los datos: representan un resumen de la información contenida en el objeto (commit, trees, ...) al que hace referencia el hash. Modificar los contenidos sin alterar el hash (es decir, un ataque de preimagen o ataque de colisión ) se cree que es difícil, aunque no imposible. (Si está realmente interesado, eche un vistazo al documento de 2011 de Marc Stevens ) .
Por lo tanto, al referirse a los objetos por su hash SHA, se puede verificar si los contenidos han sido manipulados. Y, dado que (casi) se garantiza que son únicos, también se pueden usar como identificadores de revisión, convenientemente.
Consulte el Capítulo 9 del libro de Git para obtener más detalles.
En palabras sencillas:
En términos matemáticos:
Hash no es la solución única para VCS distribuido. Pero cuando se trata de un sistema distribuido, solo se puede registrar el orden parcial de los eventos. (Para VCS, el evento puede ser un compromiso). Por eso es imposible mantener un número de revisión monótonamente creciente. Por lo general, adoptamos algo como reloj vector (o marca de tiempo vector) para registrar dicha relación ordenada parcialmente . Esta es la solución utilizada en Bazaar .
Pero, ¿por qué Git no usa el reloj vectorial sino el hash? Creo que la causa raíz es cherry-pick . Cuando realizamos la selección en un repositorio, el orden parcial de las confirmaciones está cambiando. Los relojes vectoriales de algunas confirmaciones deben reasignarse para representar el nuevo orden parcial. Sin embargo, tal reasignación en el sistema distribuido induciría relojes vectoriales inconsistentes. Ese es el verdadero problema con el que tratan los hashes.
Lea otras preguntas en las etiquetas git version-control