この記事の途中に、以下の記事の引用を含んでいます。
Note that ambiguous commit IDs are not even remotely as scary (2024)
コミットIDは短いほうが良い？リーダビリティと現実の課題
Gitの短縮コミットID（SHA1）は、長くなるほど安全と言い続けてきた現場は多いのではないでしょうか。
「SHA1が12桁だとバースデーパラドクス的に衝突が起きる！」と心配する声や、「最低16桁必要だ」といった風潮も、開発現場でしばしば耳にします。
ですが、この記事で取り上げるのは、Linuxカーネル生みの親であり、Gitそのものの生みの親でもあるLinus Torvalds氏の「短縮SHA1への本音」です。
曰く、「曖昧なコミットIDは、そんなに怖がるほどのものじゃない」
── この主張は、いったいどんな根拠に立脚しているのでしょうか。
Linusの主張：「SHA1短縮表記の曖昧さ」を過剰に恐れる必要はない
記事でTorvalds氏は、短縮コミットIDの曖昧さが“現場で恐れられすぎている”ことを問題視しています。
以下のような発言が、議論の本質を鋭く指摘しています。
Note that ambiguous commit IDs are not even remotely as scary as this implies.
My tree is at about 1.3M commits, so we’re basically an order of magnitude off the point where collisions start being an issue wrt commit IDs.
Can you find collisions by looking at all objects? Yes. Git will do that for you, and tell you their types.
To get an ambiguous ID, you have to go down to 6 characters, and even then git will tell you there’s only one object that is a commit…
（意訳）
「コミットIDの曖昧さは、そんなに怖いものじゃない。Linuxカーネルのリポジトリも130万コミットほどあるが、衝突（コリジョン）が深刻な問題になるまでには1桁分規模が違う。全オブジェクトを見れば確かに衝突はあるが、たとえば6桁まで短縮してやっと曖昧なIDが現れるくらいで、その場合もGitは型情報で区別してくれる。」
また、記事中では以下のような具体例も示されています。
with just 7 characters, you get commits like 95b861a that actually have three ambiguous commit IDs. And you still get ambiguous results with 9 characters. With 10 characters, there are no collisions. So the “we’re an order of magnitude off” seems about right – …and remember: we’re an order of magnitude off AFTER 20 YEARS OF GIT HISTORY.
つまり、20年以上のGitの運用実績でも、「短縮表記による衝突」は現実的な脅威ではない、というのです。
その主張を解き明かす：衝突のリスクと実用上の落とし穴
バースデーパラドクスと実データ
「バースデーパラドクス」とは、有限の選択肢しかない場合に、予想より早く「同じものが2つ出る（衝突が起きる）」現象です。
コミットID（SHA1）は16進40桁となるため、数十億以上の組み合わせが存在します。
しかし、現実には「すべてのコミットがSHA1として均等に分布」するわけではありません。
さらに、コミットは「Gitオブジェクト全体の1/8程度」しかなく、多数のblobやtreeなどとID空間を共有しているものの、実際にユーザーが参照するのは「ほぼコミット」だけです。
Linusの言う「曖昧になるためには6〜9桁へ極端に短縮する必要がある」というのも、これに基づくデータ的な冷静さに由来します。
たしかに「全オブジェクト」の短縮IDが衝突しても、Gitコマンドは型を判別し自動で補助する仕様です。
特に「コミット」と「blob」や「tree」は異なる種類として認識される点に着目すべきでしょう。
未来のリスクは本当に高くなるのか？
よく「将来的にコミット数が増えれば、曖昧さの問題はますます深刻」と考えられがちですが、Linusはこう論破します。
Yes, there will be more commits in the future, but it’s not going to suddenly make old SHA ID’s somehow more ambiguous…
つまり、「将来コミットが増えても、過去のIDの曖昧さが急増するわけではない。
なぜなら、コミット参照には“そのコンテキスト（時点）”も関わるからだ」と。
たとえば過去の議論やパッチメッセージ、修正理由など、コミットID以外の手がかりも併用されます。
また、短縮IDを使う場合「最初のコミットメッセージの一行目（shortlog）」などを併記すれば、「誰の目にも十分に一意」で意味が伝わります。
むしろ“人間に分かりやすい”短縮IDの意義
ここでLinusは、想像以上に「読者・開発者の可読性」を気にしています。
long git commit IDs are actually detrimental to legibility. I try to make commit messages legible, and that very much is the point of the short format. It’s for people, not machinery.
「長すぎるコミットIDは可読性を損なう。短縮表示は人間のためにある」
この発言は、「セキュリティや厳密さ」よりも、コードレビューや議論時のスムーズなコミュニケーションに重きを置いた、極めて実用主義的な見解だと言えるでしょう。
さらに深掘り：真の問題は“IDの短さ”ではなかった！
記事後半でLinusは次のように論点を展開します。
if you rely too much on the SHA1, your workflow is ALREADY broken, and it has nothing to do with the shortening.
You can find real examples of much shorted commit IDs in the kernel, and real examples of the MUCH MORE REAL issue of wrong commit ID’s right now.
つまり、本質的な問題は「短縮IDの曖昧さ」ではなく、
- 間違ったIDを書いてしまった（rebase等による参照漏れ）
- コミットメッセージが情報として不十分
- SHA1の物理IDに依存し過ぎている運用フロー
だと喝破しています。
実際、記事中でも
2e61c646edfa (“mlx4_core: Use mmiowb() to avoid firmware commands getting jumbled up”)
which refers to commit 66547550 (“IB/mthca: Use mmiowb() to avoid firmware commands getting jumbled up”).
That commit doesn’t exist at all – it’s not ambiguous due to being short, it’s ambiguous due to being wrong (presumably due to a rebase).
このように「コミットID自体が消えている（=間違って付記された）」例が、現行Linuxカーネルでも頻発しています。
しかし、このような場合ですら「shortlog（コミットメッセージ1行目）」でgrep検索すれば、十分に目的のコミットに到達できることを具体例で示しています。
個人的考察：現場では「IDの長短」より「参照の文脈」が大事だ
筆者も現場で「Fixes: a1b2c3…」の短縮SHAをしばしば見かけます。
これまで、
– CIや自動解析のためには長いSHA1が必須
– セキュリティの観点からも16桁以上がベストプラクティス
と信じがちでした。
しかし、実際の運用で短縮IDが読めないほど曖昧になった記憶はありません。
一方で、「rebaseで古くなったコミット、手動で間違って記されたcommit ID」には何度も遭遇し、そのたびに「コミットタイトル」や「周辺の修正内容」から目的の修正を突き止めてきました。
これこそ、Linusが指摘する
「コンテキストを大切にし、人間の可読性やメッセージ性を重視したプロセス」
の有効性を物語る現場感覚だと思います。
また、Gitの運用現場では「SHA1短縮ID＋コミットメッセージ1行目」の併用が事実上のスタンダードです。
人的ミスやrebaseの“揮発性”に強いのは、明らかにコミットの内容説明や短縮IDを組み合わせた運用であり、物理IDの桁数を延ばすことではありません。
むしろ「膨大なフルSHA1をコピーペースト」する運用の方が、レビュー時・議論時の行の可読性を著しく損ないかねないことにまで注意を払うべきでしょう。
結論：本当の問題は「どのコミットか分からないこと」ではなく「間違った文脈で参照されること」
Linus Torvaldsが今回の記事で力強く提言したのは「短縮SHA1の曖昧さを過度に恐れるよりも、運用とツールの文脈・人・メッセージを重視せよ」という哲学です。
Gitの歴史20年以上で、「短縮IDが曖昧でコミュニケーション不可」な現場的障害はほぼ皆無。
むしろ
– 間違ったIDを貼る
– コンテキストを曖昧にする
– サボったメッセージや説明不足
といった、人間由来の「参照不能状態」こそ本当のリスクです。
今後もコミット数は増え続けますが、「IDの長さという機械的安全策」より
「伝える文脈、ツールの使い方、可読性」を優先することが、開発組織にとっての生産性と健全性につながるでしょう。
そしてもし、あなたの現場で「16桁がいいのか12桁がいいのか」と迷ったなら、
「本当に重要なのはなんだろう」「どんな参照だと“伝わる”のか」と自問してみてください。
それがまさに、Linus Torvaldsの30年にわたるOSS開発現場からの示唆です。
categories:[technology]
コメント