ハクソク

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

Git-Annex

2025年8月25日原文(git-annex.branchable.com)

概要

  • git-annex は、Gitで大容量ファイルを管理可能にするツール
  • オフライン・オンライン問わず同期、バックアップ、アーカイブを実現
  • チェックサムや暗号化による高いセキュリティ
  • コマンドライン派には柔軟な操作性、初心者向けにアシスタントも用意
  • 多様なユースケースに対応し、将来性・拡張性も確保

git-annexの特徴

  • 大容量ファイル管理 をGitで実現、ファイル内容はGitに直接保存しない設計
  • オフライン・オンライン環境での データ同期・バックアップ・アーカイブ に対応
  • チェックサム や 暗号化 によるデータの安全性
  • Gitの 分散型構造 を活かした大容量ファイルの管理
  • コマンドラインユーザー向けの高機能な操作性
  • git-annex assistant による、初心者でも使いやすいフォルダ同期機能
  • ウォークスルー で導入手順や使い方を簡単に体験可能

ユースケース：アーキビスト Bob

  • 多数のドライブにデータをアーカイブ、ほとんどをオフラインで安全に保管
  • 単一のディレクトリツリー で全ファイルを管理、内容はオフラインでもOK
  • ファイルの再編成や新バージョンのコミットも安全に実行
  • 必要なファイルが どのドライブにあるか を即時特定可能
    • 各ドライブが他の全ドライブの内容を把握
  • シンプルなリポジトリフォーマットで 将来の可用性 も確保
  • 夜間に cronジョブ で新ファイルを自動アーカイブ
  • 意図的・非意図的なコピーも追跡、バックアップ戦略の最適化に活用

ユースケース：ノマド Alice

  • ノートPCやUSBドライブ、クラウド、サーバーなど 多様なデータソース を持ち運び
  • すべてのデータソースを gitリモートのように一元管理
  • 手動同期やファイルの場所管理の手間を削減
  • 回線が弱い時はサーバーで ファイルをキューイング、後でUSBへダウンロード
  • モバイル環境や省電力時は USBからPCへコピー して効率的に利用
  • 作業終了後は 不要ファイルを削除、次回同期時に変更をサーバーへ反映
  • 分散バージョン管理 で、どこにいてもデータの整合性を維持

git-annexの将来性とコミュニティ

  • 小さな重要ファイル はGit、大容量ファイルはgit-annexで一元管理
  • Free Software としてHaskellで開発、誰でも貢献可能
  • Ikiwiki によるWiki、 Branchable でホスティングされた活発なコミュニティ
  • ドキュメントやユーザー事例も充実、導入・運用のハードルが低い

Hackerたちの意見

コマンドラインのドキュメントにユースケースがしっかり載ってるのを見ると嬉しいね。いつも「多分使わないようなマイナーなコマンドフラグ」から始まるけど。

git-annexを使って、すべてのドライブのデータを管理してるよ。どのファイルがどのドライブにあるか自動で追跡してくれるし、コピーも十分に確保してくれるし、すべてのファイルのチェックサムも取ってくれる。オフラインのドライブでも完璧に動くよ。git-annexはちょっと難しいかもしれないから、使い捨てのリポジトリを作って、ウォークスルーに従って試してみるのをおすすめするよ。[1] https://git-annex.branchable.com/walkthrough/ [2] https://git-annex.branchable.com/workflow/

└

どれくらいのデータを持ってるの？俺は写真にgit-annexを使ってて、約10万〜100万ファイル、数TBのデータがZFSにあるんだ。最初はすごく良かったけど、だんだん遅くなってきて、今では操作が数分（5〜30分くらい）かかるようになっちゃった。これがZFSのせいなのか、git-annexのせいなのか、もしくはディスクの問題なのか、ちょっと気になってる。

└

過去にこれをやろうと思ったことがあるけど、いくつかの問題にぶつかったんだ（その一つが、一度追加したファイルを永久に削除するのが面倒だったこと）。もし時間があれば、どう使ってるのか教えてもらえると興味あるな。

Git-Annexはすごくクールな技術だけど、個人用リポジトリに最適って印象があるな。例えば、@nolist_policyが別のコメントで説明してたように、いろんなデバイスで個人ファイルやドキュメント、音楽などを管理するのに向いてる。大きなファイルを共同作業のリポジトリで同期するために使ってみたけど、「マジック」ブランチの使い方はあまりスケールしなかったな。

└

人それぞれかもしれないけど、うちの組織ではうまくいってるよ。うちはアーカイブ機関で、デジタルリポジトリシステムのストレージバックエンドとして、10年以上もgit-annexを使ってる。正直、スタッフは15～20人しかいないけど、データは30TB以上、ファイル数は約75万（バイナリとメタデータを含む）、何百ものコレクションリポジトリがあるんだ。

9日前に「Gitの大きなファイルの未来はGitにある」についての関連ディスカッションがあったよ: https://news.ycombinator.com/item?id=44916783

└

ありがとう！あんまり関係ないけど、スレッドのコメントで書いた理由もあるんだ: https://news.ycombinator.com/item?id=44922405 つまり、annexは「gitの大きなファイル」とは別の問題領域にあるんだよね、明らかな重複があるけど。考え方としては、git-annexはLFSみたいなものの「サーバーサイド」でのストレージ問題に対する、gitネイティブで分散型の解決策って感じかな。そこから考えるといいよ。

ページには書いてないけど、git-annexは https://www.patreon.com/joeyh によって作られたもので、彼は素晴らしい https://joeyh.name/code/moreutils/ や https://etckeeper.branchable.com/ も作ったんだよ。

└

より有名な（俺にとっては）、彼は1996年から数十年にわたってDebianのコアコントリビューターだったんだ。Linuxの大部分は彼のキーボードから生まれたと言っても過言じゃないね。

自ホストのforgejoを使ってるけど、今のところgit-annexがLFSより優れてる点が見当たらないな。annexを簡単にセットアップできるかもわからないし。調べてみたら、git-annexはHaskellで書かれてるみたいで（あんまり好きじゃない）、50%遅いみたい（Haskellから来る予想だけど、今のところソースが1つだけだからあんまり信頼性はない）。コマンドの複雑さには魅力を感じないな。多分目的はあるんだろうけど。一度.git-LFSの.gitattributesを開けば、必要なことはほぼわかるし、あまりコマンドも必要なくなる。あと、.gitattributeを設定すると、.gitignoreと同じようにすべてが透明になるのが好きなんだ。git-annexにはその同等のものが見当たらないな。最後に、「git lfs ls-files」の同等のものを見せない「チュートリアル」やガイドは、絶対に魅力を感じないよ。俺は「git status」や「git lfs ls-files」を使って、すべてを確認したり再確認したりするのが好きだから。

└

Forgejoのソフトフォークがあって、git-annexのサポートが追加されてるよ: https://codeberg.org/forgejo-aneksajo/forgejo-aneksajo

Hacker Newsで議論の続きを見る