Gitの次の10年に向けた進化

 (lwn.net)
21 ポイント 投稿者 GN⁺ 2026-02-16 | 1件のコメント | WhatsAppで共有
  • 世界中の開発者が使う Git が、今後10年を見据えて構造的な変化を進めており、セキュリティ・拡張性・使いやすさを軸に主要な刷新が行われている
  • 最も目立つ変化は SHA-1 から SHA-256 への移行で、2030年までに SHA-1 の使用が禁止される予定だが、エコシステムの対応不足により導入は遅れている
  • Reftable の導入により、数百万個の参照を効率的に管理し、ファイルシステムの制約や並行性の問題を解決しようとする取り組みが進んでいる
  • 大容量ファイル処理の改善に向けて Large-object promisors と プラガブルなオブジェクトデータベース が開発されており、Git 2.50 以降のバージョンで段階的に統合が進んでいる
  • Jujutsu のような新興のバージョン管理システムの影響を受け、Git は UI の簡素化と新しいコマンドの追加を通じて、現代的なワークフローを支援しようとしている

Gitに変化が必要な理由

  • Git は 2005 年の登場以来 20 年にわたり、数百万のリポジトリと無数のスクリプトに依存される中核ツールとして定着してきた
    • しかし、SHA-1 のセキュリティ脆弱性、大規模リポジトリの増加、CI パイプラインの普及 など環境の変化により、構造的な限界が明らかになってきた
  • SHA-1 は 2017 年に CWI と Google による SHAttered 攻撃 で衝突可能性が実証された
    • GPU の計算能力向上により、大規模組織がハッシュ衝突を計算できる水準に達している
  • Git は革新的な再設計よりも 漸進的な進化 を選ぶ必要があり、既存エコシステムとの互換性を保ちながら変化を進めている

SHA-256 への移行

  • Git 2.29（2020 年 10 月）で SHA-256 対応 が追加されたが、GitHub など主要プラットフォームは未対応の状態
    • Git、Dulwich、Forgejo は完全対応、GitLab・go-git・libgit2 は実験的対応の段階
  • SHA-1 は単なる完全性検証用として使われているが、署名・CI・スクリプト などエコシステム全体が衝突耐性を前提に動作している
  • 政府や企業の規制により 2030 年までの SHA-1 排除が求められており、Git 3.0 では SHA-256 がデフォルト に切り替わる予定
  • エコシステム移行のため、ユーザーが ツールのテストや forge への対応要請 を通じて参加することが推奨されている

Reftable の導入

  • 従来の Git は各参照を個別ファイルとして保存する loose reference 構造 を使っている
    • 数千万の参照を持つリポジトリでは非効率で、ファイルシステムの大文字小文字区別の問題 や 並行性の不整合 が発生する
  • Reftable は バイナリフォーマットベースのテーブル構造 で、原子的更新と効率的な参照管理が可能
    • GitLab の 2,000 万参照を持つリポジトリの事例では、従来の packed-refs ファイルは 2GB の再書き込みが必要だった
  • Git 3.0 では Reftable がデフォルトバックエンドに切り替わり、直接ファイルへアクセスする代わりに Git コマンドを使うこと が推奨される

大容量ファイル処理の改善

  • Git はテキストファイルの圧縮には効率的だが、バイナリファイルを修正するとオブジェクト全体を再生成 するため非効率が生じる
    • GitLab の分析によれば、リポジトリ容量の 75% を 1MB 以上のバイナリファイルが占めている
  • Large-object promisors 機能は、大きなオブジェクトを別のリモートストレージに保管し、CDN や S3 API で転送できるようにする
    • Git 2.50〜2.52 でプロトコル実装が完了し、クライアント側で利用可能な段階にある
  • プラガブルなオブジェクトデータベース は、バイナリ専用の保存フォーマットを導入して増分保存を支援する予定
    • Git 2.53 で統合オブジェクトデータベースインターフェースが導入され、2.54 では概念実証（PoC）が見込まれている

ユーザーインターフェースの改善

  • Git コマンドは複雑で一貫性に欠けるという批判が続いており、Rust ベースの Jujutsu（JJ） が代替として台頭している
    • Jujutsu は 履歴の自動並べ替え、衝突をデータとして扱うこと、コミットを下書きのように扱う方式 を提供する
  • Git は既存ワークフローを壊さずに、Jujutsu の利点を一部取り込みつつある
    • Git 2.54 では git history split、git history reword コマンドが追加される予定
    • 今後さらに多くの 履歴編集サブコマンド が追加される計画
  • Steinhardt は、Git は競争を通じて学んでおり、UI のモダン化と使いやすさの向上 が進んでいることを強調している

関連記事

1件のコメント

 
GN⁺ 2026-02-16
Hacker Newsのコメント

  • Gitは本当に美しいソフトウェアだが、プログラマー中心の複雑さをそのまま露出している面がある
    開発職ではない人たちにGitを教えたことがあるが、彼らはその機能の繊細な強力さを完全には活用できなかった
    Learn Git Branching のようなサイトは素晴らしい学習リソースだ。こうしたUXがGitの基本体験に溶け込んでいるとよいと思う — 直感的なデフォルトや、段階的に学べる流れのようなものだ
    最近はClaude、Codex、OpenCodeのようなエージェントCLIを使えば、こうした体験を簡単に提供できる。だが、Git自体がもっとアクセスしやすい抽象化を提供すれば、はるかに容易になるはずだ

    • 問題はGitが複雑さを露出していることではなく、誤った用語と概念、そしてひどいドキュメントでその複雑さを表現している点だ

  • Git 3.0には本当に期待しているが、同時にすぐに落胆する準備もできている 😅
    jjはGitユーザーに大きな助けになった。より直感的なVCSフロントエンドが可能だと示してくれたからだ

    • 競争が多いほど、エコシステムには良い刺激が生まれる

  • GitLabで、2GBの packed-refs ファイルを数秒おきに書き直している事例を見たが、「いったいなぜこんなことが起きるのか」が理解できない

    • そして正直なところ、そんな状況をGitやその人が気にかけるべき理由があるのかも分からない

  • 大容量ファイルを外部に保存するのは中央集権型モデルへ向かう一歩のように見えるが、Gitの初期の設計哲学には反している

    • 必ずしもそうではない。それは単にアドレッシングモデルとインターフェースの問題だ。中央リポジトリを使うこともできるが、IPFSのような分散ストレージを使うこともできる
    • その通り。GitはDVCSであって汎用DVFSではない。私はドキュメント保存用にDVFSが必要だったので、自分で1つ作った。シンプルで高速で、目的に合ってうまく動いている

  • SHA1から移行するのに時間がかかりすぎている
    ハッシュ関数は最初からもっとモジュール化された構造で設計されるべきだった

  • Gitにはコミット単位でソフトウェアライセンス追跡機能が必要だと思う

    • 何を意味しているのか完全には理解できていないが、それはGitの仕事ではない。Gitはソースコード管理システムにすぎず、追加機能は git-annex のような拡張ツールとして実装するのが適切だ
    • Gitがそうした機能を持つと、むしろ悪くなる。コミットにはすでに任意のデータを保存できるのだから、必要なメタデータはそのままコミットに入れて、別のツールで処理すればよい
    • LLMが支援したコードのようにトレーラーを使えばよい
      例: Co-Authored-By: Whatever LLM, License: WTFPL