なぜgitはリビジョン番号ではなくハッシュを使用するのですか？

なぜgitはリビジョン番号よりもハッシュを好むのかといつも思っていました。リビジョン番号ははるかに明確で簡単に参照できます（私の意見では）：リビジョン1200を見てもらうか、92ba93eをコミットするように誰かに言うことには違いがあります！（1つの例を挙げます）。

それでは、この設計には理由がありますか？

単一の単調に増加するリビジョン番号は、すべてのリビジョンが番号を追跡して割り当てることができる単一の場所に流れる集中型バージョン管理システムにのみ意味があります。リポジトリの多数のコピーが存在し、任意のワークフローで変更がそこから取得およびプッシュされるDVCSの世界に入ると、この概念はまったく適用されません。（たとえば、リビジョン番号を割り当てる場所はどこにもありません-リポジトリを分岐し、1年後に変更をプルすることにした場合、システムはリビジョン番号が競合しないことをどのように確認できますか？）

分散システムではハッシュが必要です。あなたと同僚が同じリポジトリで作業しており、両方ともローカルで変更をコミットしてからプッシュしたとします。誰がリビジョン番号1200になり、誰もリビジョン番号1201になります。どちらの当事者にも互いの知識がありません。唯一の現実的な技術的解決策は、既知の方法を使用して変更のハッシュを作成し、それに基づいてリンクすることです。

興味深いことに、HGはバージョン番号をサポートしますが、それらは明示的にローカルのみの機能です。リポジトリには1つのセットがあり、同僚のリポジトリにはプッシュとプルの方法によって異なるセットがあります。ただし、コマンドラインの使用はGitよりも少し使いやすくなります。

データの整合性。

私は、現在の答えに敬意を表して反対します。DVCSにはハッシュは必要ありません。Bazaarの方法を参照してください。他の種類のグローバルに一意の識別子でも同様にできます。ハッシュは、データの整合性を保証する手段です。ハッシュによって参照されるオブジェクト（コミット、ツリーなど）に含まれる情報のダイジェストを表します。ハッシュを変更せずにコンテンツを変更すること（つまり、プリイメージ攻撃または衝突攻撃）は難しいと考えられていますが、不可能ではありません。（もし本当に興味があるなら、Marc Stevensによる2011年の論文をご覧ください）。

したがって、SHAハッシュでオブジェクトを参照すると、コンテンツが改ざんされていないかどうかを確認できます。そして、それらが（ほとんど）一意であることが保証されていることを考えると、それらはリビジョン識別子としても使用できます-便利です。

詳細については、Gitブックの第9章を参照してください。

素人の言葉で：

• ハッシュは、ほぼ普遍的に一意であることが意図されています。それは保証が、されないが、非常に同じSHA年代が異なるコンテンツのために生成されているとは考えにくいです。特定のプロジェクトの実際的な用語では、それをユニークなものとして扱うことができます。
• リビジョン番号では、特にリビジョン1200を参照するためにネームスペースを使用する必要があります。
• Gitは分散型および/または集中型の両方で機能します。それでは、どのようにしてリビジョン番号を正しく一意にするのでしょうか？
• また、リビジョン番号を使用すると、新しいリビジョンには高い番号が必要であり、分岐、マージ、リベースなどのために真実ではないという誤った推測が生じます。
• コミットにタグを付けるオプションが常にあります。

数学用語で：

• 全順序のGitのコミットを超えるはmonotonallyバージョン番号を増加させるために必要とされるであろう。
• Gitのコミットは、部分的/トポロジ的にのみ順序付けられる有向非循環グラフ（DAG）を形成します。

ハッシュは、分散VCSのユニークなソリューションではありません。ただし、分散システムを扱う場合は、イベントの部分的な順序のみを記録できます。（VCSの場合、イベントはコミットです。）それが、単調に増加するリビジョン番号を維持することが不可能な理由です。通常、このような半順序関係を記録するには、ベクトルクロック（またはベクトルタイムスタンプ）のようなものを採用します。これはBazaarで使用されるソリューションです。

しかし、なぜGitはベクトルクロックではなくハッシュを使用するのですか？根本的な原因はチェリーピックだと思います。リポジトリでチェリーピックを実行すると、コミットの部分的な順序が変わります。一部のコミットのベクトルクロックは、新しい半順序を表すために再割り当てする必要があります。ただし、分散システムでのこのような再割り当ては、一貫性のないベクトルクロックを引き起こします。それがハッシュが扱う本当の問題です。