Por que o git usa hashes em vez de números de revisão?

Um único número de revisão crescente monotonicamente só faz realmente sentido para um sistema de controle de versão centralizado, onde todas as revisões fluem para um único local que pode rastrear e atribuir números. Uma vez que você entra no mundo do DVCS, onde inúmeras cópias do repositório existem e as mudanças estão sendo extraídas e enviadas para elas em fluxos de trabalho arbitrários, o conceito simplesmente não se aplica. (Por exemplo, não há um lugar para atribuir números de revisão - se eu separar seu repositório e você decidir um ano depois para extrair minhas alterações, como um sistema pode garantir que nossos números de revisão não entrem em conflito?)

Você precisa de hashes em um sistema distribuído. Digamos que você e um colega estejam trabalhando no mesmo repositório e que você faça uma alteração local e, em seguida, envie-a. Quem pode ser o número de revisão 1200 e quem é o número de revisão 1201, dado que nenhuma das partes tem algum conhecimento sobre a outra? A única solução técnica realista é criar um hash das mudanças usando um método conhecido e vincular as coisas com base nisso.

Curiosamente, o HG suporta números de versão, mas eles são explicitamente um recurso somente local - seu repositório tem um conjunto, o repositório de seu colega de trabalho terá um conjunto diferente, dependendo de como eles foram executados. Isso faz com que o uso da linha de comando seja um pouco mais amigável do que o Git.

Integridade de dados.

Eu respeitosamente discordo das respostas atuais. Hashes não são necessários para um DVCS, veja o caminho do Bazar . Você poderia fazer o mesmo com qualquer outro tipo de identificador global exclusivo. Os hashes são uma medida para garantir a integridade dos dados: Eles representam um resumo das informações contidas no objeto (commit, trees, ...) referenciadas pelo hash. Alterando o conteúdo sem alterar o hash (ou seja, um ataque de pré-imagem ou ataque de colisão ) é considerado difícil, embora não impossível. (Se você realmente gosta disso, dê uma olhada no artigo de 2011 de Marc Stevens ) .

Assim, referindo-se aos objetos pelo seu hash SHA permite verificar se o conteúdo foi adulterado. E, dado que eles são (quase) garantidos para ser únicos, eles podem ser usados como identificadores de revisão, também - convenientemente assim.

Veja Capítulo 9 do livro Git para mais detalhes.

Nas palavras do leigo:

• Os hashes pretendem ser quase universalmente exclusivos. NÃO é garantido, mas é extremamente improvável que os mesmos SHA's sejam gerados para conteúdos diferentes. Em termos práticos para um determinado projeto, você pode tratá-lo como único.
• Com números de revisão, você teria que usar um namespace para se referir especificamente à revisão 1200.
• O Git pode trabalhar tanto distribuído quanto centralizado. Então, como você consegue números de revisão corretos e únicos?
• O uso de números de revisão também criaria a falsa impressão de que as revisões mais recentes deveriam ter números mais altos, e isso não seria verdade por causa de ramificações, mesclagens, rebasings, etc.
• Você sempre tem a opção de colocar tags nos commits.

Em termos matemáticos:

• Um pedido total sobre os commits do Git seria necessário para aumentar monotonamente os números de versão.
• Os commits do Git formam um direcionado, um gráfico acíclico (DAG) que só pode ser encomendado parcialmente / topologicamente .

O hash não é a solução exclusiva para VCS distribuído. Mas quando lidamos com um sistema distribuído, apenas a ordem parcial de eventos pode ser registrada. (Para o VCS, o evento pode ser um commit.) É por isso que manter um número de revisão crescente e monotônico é impossível. Geralmente, adotamos algo como relógio vetorial (ou registro de data e hora do vetor) para registrar essa relação ordenada parcialmente . Esta é a solução usada no Bazar .

Mas por que o Git não usa clock vetorial, mas hash? Eu acho que a causa raiz é cherry-pick . Quando executamos cherry-pick em um repositório, a ordenação parcial de commits está mudando. Alguns relógios vetoriais de commits devem ser realocados para representar a nova ordenação parcial. No entanto, tal reatribuição no sistema distribuído induzia relógios vetoriais inconsistentes. Esse é o verdadeiro problema com o qual as hashes lidam.