TLDR;
あなたは、からそれをチェックすることができ、彼は2007年に、Googleの背面にGitリポジトリを提示したときに、Linus Torvalds氏自身：
（強調鉱山）
暗号的に安全であると考えられるチェックサムをチェックします。誰もSHA-1を破ることができませんでしたが、要点は、gitに関する限り、SHA-1はセキュリティ機能でさえありません。これは純粋に整合性チェックです。
セキュリティパーツは別の場所にあります。多くの人々は、gitがSHA-1を使用し、SHA-1は暗号的に安全なものに使用されるため、それは巨大なセキュリティ機能であると考えています。これはセキュリティとは何の関係もありません。入手できる最高のハッシュにすぎません。
優れたハッシュは、データを信頼できるため、他にもいくつかの優れた機能があります。つまり、オブジェクトをハッシュすると、ハッシュが適切に分散されていることがわかり、特定の分散の問題を心配する必要がなくなります。 。
内部的には、実装の観点から見ると、ハッシュが非常に優れているため、ハッシュアルゴリズムを使用でき、悪いケースがないことを確信できます。
したがって、暗号化の側面も好きになるいくつかの理由がありますが、それは本当にあなたのデータを信頼する能力についてです。
データをgitに入れれば、ハードディスクからDVDに変換されて新しいテクノロジーに変換されてコピーされた後、5年後にデータを検証できるという事実を信頼できます。取り戻すのは、入力したのとまったく同じデータです。そして、それは、ソースコード管理システムで本当に探す必要があるものです。
2017年12月にGit 2.16で更新（2018年第1四半期）：代替SHAをサポートするこの取り組みが進行中です：「なぜGitはより最新のSHAを使用しないのですか？」を参照してください。
「BLOBでSHA-1の衝突をgitはどのように処理しますか？」で、特定のSHA1 プレフィックスを使用してコミットを設計できると述べました（まだ非常にコストのかかる作業です）。
しかし、Eric Sinkが " Git：Cryptographic Hashes "（Version Control by Example（2011）book）で述べているように、要点は残っています。
DVCSが同じダイジェストを持つ2つの異なるデータに遭遇しないことが重要です。幸いなことに、優れた暗号化ハッシュ関数は、このような衝突をほとんど起こさないように設計されています。
「遺伝的プログラミングによる最先端の非暗号化ハッシュの検索」のような研究を考慮しない限り、衝突率の低い適切な非暗号化ハッシュを見つけることは困難です。
また、「ハッシュの高速化のために非暗号化ハッシュアルゴリズムの使用を検討する」を読むこともできます。たとえば、RAM制限に近い速度で動作する非常に高速な非暗号化ハッシュアルゴリズムである「xxhash」について説明しています。
Gitでのハッシュの変更に関する議論は新しいものではありません。
（ライナス・トーバルズ）
mozillaコードには何も残っていませんが、そこから始めました。振り返ってみると、おそらくブロックが正常に行われたPPC asmコードから始めるべきだったと思いますが、それは「20/20後知恵」のようなものです。
さらに、Mozillaのコードが恐ろしい山積みになっていることが、私が物事を改善できると確信していた理由です。ですから、実際の残りのコードよりも動機付けの側面についての情報であるとしても、それは一種のソースです;）
そして、実際の最適化ゲインを測定する方法に注意する必要があります
（ライナス・トーバルズ）
私はあなたがgccにがらくたコードを生成させ、それがP4の問題のいくつかを隠すためだけにそれが物事を改善することをあなたに保証することができます。
（ジョン・タプセル- johnflux）
gitをSHA-1から新しいアルゴリズムにアップグレードするためのエンジニアリングコストははるかに高くなります。どうすれば上手くいくのかわかりません。
まず最初に、おそらくgitのバージョンをデプロイする必要があります（この会話ではバージョン2と呼びましょう）。これにより、そのスペースを読み取ったり使用したりしなくても、新しいハッシュ値用のスロットができるようになります。他のスロットにあるSHA-1ハッシュ値。
このようにして、最終的にgitの新しいバージョンをデプロイしたら、バージョン3と呼びましょう。これにより、SHA-1ハッシュに加えてSHA-3ハッシュが生成され、gitバージョン2を使用しているユーザーは引き続き相互運用できます。
（ただし、この説明では、脆弱性が存在する可能性があり、SHA-1のみのパッチに依存する人々が脆弱性を持っている可能性があります。）
要するに、スイッチング任意のハッシュは容易ではありません。
2017年2月の更新：はい、衝突SHA1を計算することは理論的には可能です：shattered.io
GITはどのように影響を受けますか？
GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックをSHA-1に強く依存しています。
基本的に、同じヘッドコミットハッシュと異なる内容の2つのGITリポジトリを作成することが可能です。たとえば、良性のソースコードとバックドアされたものです。
攻撃者はいずれかのリポジトリをターゲットユーザーに選択的に提供する可能性があります。これにより、攻撃者は独自の衝突を計算する必要があります。
だが：
この攻撃には、9,223,372,036,854,775,808以上のSHA1計算が必要でした。これには、6,500年のシングルCPU計算と110年のシングルGPU計算と同等の処理能力が必要でした。
だから、まだパニックにならないようにしましょう。
詳しくは、「GitはblobでのSHA-1衝突をどのように処理しますか？」を参照してください。