ハクソク

世界を動かす技術を、日本語で。

ハイパフォーマンスGit

17時間前原文(gitperf.com)

概要

  • Gitは単なるバージョン管理ツール以上の多層的なシステム
  • 各レイヤーごとのパフォーマンスコストに焦点を当てた解説
  • オブジェクト、参照、インデックス、履歴探索から始まる構成
  • パックファイルやメンテナンス、スケーラビリティもカバー
  • エンジニアや大規模リポジトリ管理者向けの内容

Gitの多層構造とパフォーマンス

  • Gitはバージョン管理ツールでありながら、コンテンツアドレス型データベース、ファイルシステムキャッシュ、グラフウォーカー、転送プロトコルの側面を持つ
  • 本書はこれら各レイヤーの仕組みと、それぞれのパフォーマンスコストを解説
  • 最初にオブジェクト、リファレンス（refs）、インデックス、履歴探索の基礎構造を扱う
  • 次にパックファイル、メンテナンス作業、スパースワーキングツリー、部分的なクローン、転送プロトコルなど外側の仕組みに進む
  • リポジトリの規模、診断、設定、リカバリーまでを網羅

対象読者

  • リポジトリや履歴、チームの拡大に伴い、Gitの高速性維持が求められるエンジニア
    • Buildエンジニア、CIエンジニア
    • モノレポ（monorepo）管理者
    • Developer-experienceチーム
    • Gitの不可解な挙動をデバッグする担当者
  • 簡単な説明では解決できない問題に直面した際に役立つ知識の提供

Hackerたちの意見

> LFSは独自の運用オーバーヘッドを追加するんだよね。すごく小さいリポジトリでも、リモート操作のコマンドごとに数秒かかる感じ。
└
さらに悪いことに、約半年間、LFSを使うときにYubikeyでed25519-skキーを3回も認証しなきゃいけないんだよね。プッシュするたびに。
└
Git annexを選ばなかったのは、まさにNIHの間違いだったね。
まだ第2章に入ったばかりだけど、今までずっと見逃してた配管の詳細が説明されてて、めっちゃいいね。
└
ありがとう！その章が独立して成立することを願ってたんだ。それとパックファイルの章は、最初に書いたもので、自分のための参考にもなってる！
Gitは業界標準だよね。だって、提供されるものに対して、驚くほど頑丈でシンプルなプログラムだから。内部の仕組みが複雑なのはみんななんとなく知ってるけど、UXはクリーンで使いやすいから、複雑さが表に出てこないんだよね。でも、これが崩れて、ブルームフィルターやパックファイル、Gitのガベージコレクターの管理やrerereのクリーンアップに対処しなきゃならなくなったら、コードベースを中央集権型VCSに切り替える日が来ると思う。この辺のことを学ぶのは面白いけど、日常の仕事で考えたいことからは5層も離れてる。
└
Gitが業界標準なのは、ほぼ完全にGitHubのおかげだと思う。UXがクリーンだなんて全然同意できない。CLIはちょっとめちゃくちゃだよね。
└
逆だと思う。Gitは内部的にはかなりシンプルで、そのUIはそのシンプルで信頼できる内部構造にアクセスするためのつまみやレバーみたいなもんだ。だから人によっては混乱して見えるんだろうな。「自分の思い通りにやってくれ」ってボタンを求める人もいるし、他の人にはクリーンに感じるんだ。アクセルを開ければエンジンが回る。
コードを扱っているときにGitのパフォーマンス問題に直面したことはなかったな。たぶん、私のリポジトリが大きくなかったから。でも、ペットプロジェクトで変更のバージョン管理にGitを使おうとしたとき、インデックスやコンパクションについてたくさん学んだよ。この記事はたくさんのことをカバーしていて、とても役立つ！
└
WindowsでのGitは明らかに遅いよね。GitはUnixコマンドの上で動くように作られてるから、LinuxやMacでは問題ないんだけど、Windowsだとコマンドを別途インストールしなきゃいけないし、そのたびにパフォーマンスが落ちるんだ。個々のGitコマンドは大丈夫だけど、いくつかのステップを連続で呼び出すと、目に見えて遅くなるよね。（WSLを使えばこれを完全に回避できるけど。）
同様に、パフォーマンスにこだわらないなら、『Building Git』を心からおすすめするよ。Rubyで自分のGitクローンを作る方法を教えてくれるんだ（言語は関係ないけどね）。[0]: https://shop.jcoglan.com/building-git/
驚いた、驚いた、またHNのフロントページにLLM生成のゴミが載ってる。第1章から: > 「Gitが遅くなると、エンジニアは悪い方法で適応する。歴史が答えられる質問を聞くのをやめ、同期コストを避けるために作業をまとめ、乱雑なブランチを長く生かし、クリーンアップを後回しにし、リポジトリを少し危険なもののように扱う。」 > 「機械が機械のペースでコードを生成し始めると、この本のモデルは壊れない。変わるのはペースだけで、より多くのブランチ、より多くのコミット、より多くの自動化、そして周囲のメタデータが増える。トラフィックはうるさくなり、圧力の下でGitを読みやすく保つ機能は「あったらいいな」から「必須」に変わる。」 > 「これらはもはやサイド最適化のようには見えない。機械規模のGitトラフィックを使える状態に保つためのものだ。」
└
同じことを考えた。正直に言うと、あの個々の文にはAIっぽさは感じないけど、全部を合わせて読むと確かにそう思える。何がそうさせるのかは分からないけど、普通の人間の声には聞こえなくて、むしろ印象的に聞こえようとするキャラクターの独白みたいな感じ。
└
このLLM的な表現はまだ目立つけど、こういう技術的な内容の接着剤的な部分としては耐えられるかな。もしかしたら、もうAIの精神病に迷い込んでるのかもしれないし、純粋な合成の「無人のゴミ」から「受け入れられるゴミ」に移行しようとしてる人もいるかも。著者が持っている業界経験を反映したプロンプトを得て、それをgitのコードベースやドキュメントに指し示すことができる人もいるかもしれない…私の場合（gitパフォーマンスにはあまり関わってないから、私のgitはトリビアルだけど）、知識が限られているセクションの説明はとても参考になる。
これが取り上げられて嬉しいし、正直言って、すごくマニアックな分野に興味を持たれて驚いてる。いくつかのこと: - 小さなエラーを修正し、いくつかの章の内容を改訂し、一般的な無駄を削除したEdition 1.1をリリースしたよ。これをバージョン管理しようと思ってる。 - Gitに新しいことが来る予定で、近いうちに「Gitの未来」や「ポストGitの世界」について話すかもしれない。 - 無料のPDFもあるよ、https://gitperf.com/pdf.html - 実用的な章もいくつか近々出す予定で、実践的な組織の導入に焦点を当ててる。例えば、git CLIをベストプラクティスにラップすることについて。
Gitで一番恋しいのは、簡単なスパースチェックアウトかな。svnのように特定のパスだけをチェックアウトできるのがいいな。
Gitのデータ構造は驚くほどシンプルだよ。基本的な4つのデータタイプについての図解付きの記事がある。なぜ「HEAD」が「commit」と違うのかも説明してる。https://eagain.net/articles/git-for-computer-scientists/
└
HEADって単にコミットの参照じゃないの？Gitには基本的に「もの」が二つしかない、refsとobjects。Gitの内部はすごくシンプルだから、個人的にはこのチュートリアル[0]を最初にやった方がいいと思う。Gitの表面だけを学ぶより、何が起こってるのかを理解するのがずっと楽になるよ。[0]: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
メガコープが持ってる fancyな開発ツールに触れられないのが本当にイライラする。例えば、Metas Saplingなんかは、彼らがGit互換のVCSを自分たちのスケールでうまく動かすための方法らしい。確かに名目上はオープンソースだけど、「まだ公開サポートされてない、OSSはサポート外の実験用にビルド可能」みたいな注意書きがあって、カジュアルなユーザーは手を出しづらいよね。あと、他のもそれぞれ独自のものを持ってるけど、ほとんどがさらに公開されてないし。 https://github.com/facebook/sapling