gitがリビジョン番号の代わりにハッシュを使用するのはなぜですか？
なぜgitはリビジョン番号よりもハッシュを好むのかといつも思っていました。リビジョン番号はより明確で参照しやすい（私の意見では）：リビジョン1200を確認するように指示するか、92ba93eをコミットするよう指示するかには違いがあります。 （一例を挙げるだけです）。
それで、このデザインには理由がありますか？
単一の単調に増加するリビジョン番号は、すべてのリビジョンが番号を追跡して割り当てることができる単一の場所に流れる中央集中型のバージョン管理システムにのみ意味があります。 DVCSの世界に入ると、リポジトリのコピーが多数存在し、任意のワークフローで変更がプルされ、そこにプッシュされますが、この概念は適用されません。 （たとえば、リビジョン番号を割り当てる場所は1つではありません。リポジトリをフォークし、1年後に私の変更をプルすることを決定した場合、どのようにしてシステムがリビジョン番号が競合しないようにすることができますか？）
分散システムではハッシュが必要です。あなたと同僚が同じリポジトリで作業していて、変更をローカルでコミットしてからプッシュするとします。どちらの当事者もお互いについて知識がない場合、誰がリビジョン番号1200になり、誰がリビジョン番号1201になりますか？唯一の現実的な技術的解決策は、既知の方法を使用して変更のハッシュを作成し、それに基づいて物事をリンクすることです。
興味深いことに、HGはバージョン番号をサポートしていますが、これらは明らかにローカルのみの機能です。リポジトリには1つのセットがあり、同僚のリポジトリには、プッシュとプルの方法に応じて異なるセットがあります。ただし、コマンドラインの使用はGitよりも少しフレンドリーです。
データの整合性。
現在の回答には敬意を払いません。 DVCSではハッシュは必要ありません。 Bazaarの方法 を参照してください。他の種類のグローバルに一意の識別子を使用することもできます。ハッシュはデータの整合性を保証する手段です。ハッシュは、ハッシュによって参照されるオブジェクト（コミット、ツリーなど）に含まれる情報のダイジェストを表します。ハッシュを変更せずにコンテンツを変更すること（つまり、 プリイメージ攻撃 または 衝突攻撃 ）は、不可能ではありませんが、難しいと考えられています。 （あなたが本当にそれに興味があるなら、 Marc Stevensによる2011年の論文 を見てください）。
したがって、SHAハッシュでオブジェクトを参照すると、コンテンツが改ざんされていないかどうかを確認できます。また、（ほとんど）一意であることが保証されているため、リビジョンとして使用できます識別子も-便利です。
詳細については、Gitブックの 第9章 を参照してください。
素人の言葉で：
- ハッシュは、ほぼ普遍的に一意であることを意図しています。保証はありませんが、異なるコンテンツに対して同じSHAが生成される可能性はほとんどありません。特定のプロジェクトの実際の用語では、それをユニークなものとして扱うことができます。
- リビジョン番号では、特にリビジョン1200を参照するために名前空間を使用する必要があります。
- Gitは分散型でも集中型でも動作します。では、どのようにしてリビジョン番号を正しくユニークなものにできますか？
- また、リビジョン番号を使用すると、新しいリビジョンはより高い番号を持つべきであるという誤った見方が生まれ、ブランチ、マージ、リベースなどのためにそうではありません。
- コミットにタグを付けるオプションは常にあります。
数学的に：
- バージョン番号を単調に増加させるには、Gitのコミットを超える total order が必要になります。
- Gitのコミットは directed、acyclic graph（DAG） の形式であり、順序付けのみ可能 partialally/topologically です。
ハッシュは、分散型VCSのユニークなソリューションではありません。ただし、分散システムを処理する場合、記録できるのはイベントの部分的な順序のみです。 （VCSの場合、イベントはコミットである可能性があります。）そのため、単調に増加するリビジョン番号を維持することは不可能です。通常、ベクトルクロック（またはベクトルタイムスタンプ）のようなものを採用して、そのような半順序関係を記録します。これは Bazaar で使用されるソリューションです。
しかし、なぜGitはベクトルクロックではなくハッシュを使用するのでしょうか。根本的な原因はcherry-pickだと思います。リポジトリでチェリーピックを実行すると、コミットの部分的な順序が変わります。一部のコミットのベクトルクロックは、新しい部分的な順序を表すために再割り当てする必要があります。ただし、分散システムでのこのような再割り当ては、一貫性のないベクトルクロックを引き起こします。それがハッシュが扱う本当の問題です。