Gitを使用した大きなバイナリファイルの管理

私のソースコード（Webアプリケーション）が依存している大きなバイナリファイルを処理する方法についての意見を探しています。現在、いくつかの代替案について検討しています。

1. バイナリファイルを手動でコピーします。
   • プロ：わからない。
   • 反対：新しいサイトの設定や古いサイトの移行時にエラーが発生する可能性が高くなるので、私はこれに強く反対します。取るべき別のハードルを構築します。
2. すべてGitで管理します。
   • プロ：重要なファイルをコピーすることを「忘れる」可能性を排除
   • 反対：リポジトリを膨らませ、コードベースを管理するための柔軟性を低下させ、チェックアウト、クローンなどはかなり時間がかかります。
3. 個別のリポジトリ。
   • プロ：ソースコードのチェックアウト/クローンはこれまでになく高速で、イメージは独自のリポジトリに適切にアーカイブされます。
   • 反対：プロジェクトにGitリポジトリが1つしかないという単純さを排除します。それは確かに私が考えていないいくつかの他のものを紹介します。

これに関するあなたの経験/考えは何ですか？

また：誰かが複数のGitリポジトリを使用して1つのプロジェクトでそれらを管理した経験はありますか？

ファイルは、それらのファイルを含むPDFを生成するプログラムの画像です。ファイルはそれほど頻繁には変更されませんが（年単位で）、プログラムに非常に関連しています。プログラムはファイルなしでは機能しません。

プログラムがファイルなしで機能しない場合、それらを個別のリポジトリに分割することは悪い考えです。個別のリポジトリに分割する大規模なテストスイートがありますが、これらは本当に「補助」ファイルです。

ただし、別のリポジトリでファイルを管理し、それを使用git-submoduleして正常な方法でプロジェクトにそれらをプルすることができる場合があります。したがって、すべてのソースの完全な履歴は保持されますが、私が理解しているように、イメージサブモジュールの関連するリビジョンは1つしかありません。このgit-submodule機能は、正しいバージョンのコードを正しいバージョンのイメージと一致させるのに役立ちます。

以下は、Git Bookのサブモジュールの良い紹介です。

私は素晴らしいgit-annexを最近発見しました。大きなファイルを効率的に管理するために設計されました。写真や音楽などのコレクションに使用しています。git-annexの開発は非常に活発です。ファイルのコンテンツはGitリポジトリから削除できます。ツリー階層のみがGitによって追跡されます（シンボリックリンクを介して）。ただし、ファイルのコンテンツを取得するには、プル/プッシュ後に2番目のステップが必要です。例：

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

利用可能な多くのコマンドがあり、ウェブサイトにはすばらしいドキュメントがあります。パッケージはDebianで入手できます。

2015年4月以降のもう1つのソリューションは、Git Large File Storage（LFS）（GitHubによる）です。

これは、使用のgit-LFSを（参照git-lfs.github.comを）し、それをサポートするサーバーでテスト：LFS-テストサーバー：
あなただけのgitリポジトリ、および他の場所で大きなファイルにメタデータを格納することができます。

大きなバイナリをGitリポジトリにスマートに格納するためのGit拡張であるgit bupをご覧ください。

あなたはそれをサブモジュールとして持つことを望みますが、リポジトリが扱いにくくなることを心配する必要はありません。サンプルユースケースの1つは、VMイメージをGitに保存することです。

実際のところ、圧縮率は向上していませんが、私のリポジトリには大きなバイナリは含まれていません。

あなたのマイレージは異なる場合があります。

あなたも使うことができます git-fatを。私はそれが在庫のPythonとにのみ依存するのが好きですrsync。また、次の自明のコマンドを使用して、通常のGitワークフローもサポートします。

git fat init
git fat push
git fat pull

さらに、.gitfatファイルをリポジトリにチェックインし、.gitattributesを変更してgit fat、管理するファイル拡張子を指定する必要があります。

通常のを使用してバイナリを追加すると、gitattributesルールに基づいてgit add呼び出さgit fatれます。

最後に、バイナリが実際に保存されている場所をリポジトリやユーザー間で共有でき、何でもサポートできるという利点がありますrsync。

更新：Git-SVNブリッジを使用している場合は、git-fatを使用しないでください。最終的には、Subversionリポジトリからバイナリファイルが削除されます。ただし、純粋なGitリポジトリを使用している場合は、美しく機能します。

サブモジュール（Pat Notzとして）または2つの異なるリポジトリーを使用します。バイナリファイルを頻繁に変更する場合は、巨大なリポジトリが履歴を消去する影響を最小限に抑えるようにします。

数か月前に非常によく似た問題がありました：約21 GBのMP3ファイル、未分類（名前が悪い、id3が悪い、そのMP3ファイルが好きかどうかわからない...）、3台のコンピューターに複製されました。

メインのGitリポジトリーで外部ハード・ディスクを使用し、それを各コンピューターに複製しました。それから、私はそれらを習慣的な方法（プッシュ、プル、マージ...削除と名前の変更）で分類し始めました。

結局、私はMP3ファイルを6 GB以下、.gitディレクトリに83 GBしかありませんでした。私が使用git-write-treeし、git-commit-tree新しいコミットを作成し、先祖をコミットせずに、そのコミットを指す新しいブランチを開始しました。そのブランチの「git log」は1つのコミットのみを示しました。

次に、古いブランチを削除し、新しいブランチのみを保持し、ref-logsを削除して、「git prune」を実行しました。その後、.gitフォルダーの重みは約6 GBだけでした...

同じ方法で時々巨大なリポジトリを「パージ」することができます。「git clone」はより高速になります。

私が提案したいソリューションは、孤立したブランチとタグメカニズムのわずかな乱用に基づいています。これは、以降* Orphan Tags Binary Storage （OTABS）と呼ばれます。

TL; DR 2017年12月 1日githubのLFSまたは他のサードパーティを使用できる場合は、必ずそうするべきです。できない場合は、読み続けてください。警告してください、このソリューションはハックであり、そのように扱われるべきです。

OTABSの望ましい特性

• これは純粋なgitおよびgitのみのソリューションです。サードパーティのソフトウェア（git-annexなど）やサードパーティのインフラストラクチャ（githubのLFSなど）なしで作業を完了できます。
• バイナリファイルを効率的に保存します。つまり、リポジトリの履歴を膨らませません。
• git pullそして、git fetch、を含むがgit fetch --all残っている、効率的な帯域幅、すなわち、すべての大規模なバイナリは、デフォルトではリモートから引き出されていません、。
• Windowsで動作します。
• すべてを単一のgitリポジトリに格納します。
• （bupとは異なり）古いバイナリを削除できます。

OTABSの望ましくない特性

• それはgit clone潜在的に非効率的です（しかし、必ずしもそうではありませんが、使用方法によっては）。このソリューションを展開する場合、のgit clone -b master --single-branch <url>代わりに使用するよう同僚にアドバイスする必要があるかもしれませんgit clone。これは、デフォルトではgit cloneがレファレンス全体のクローンを作成するためです。これには、参照されていないコミットなど、通常は帯域幅を浪費したくないものも含まれます。SO 4811434から取得。
• それはなりgit fetch <remote> --tags非効率的な帯域幅が、必ずしもそうとは限らないストレージは非効率的。いつでも使用しないように同僚にアドバイスできます。
• 定期的にgit gcトリックを使用して、不要になったファイルからリポジトリをクリーンアップする必要があります。
• それはほど効率的ではありませんBUPかのgit-bigfiles。しかし、それはそれぞれあなたがやろうとしていることと、より既成のことにもっと適しています。数十万の小さなファイルやギガバイトの範囲のファイルで問題が発生する可能性がありますが、次善策については読んでください。

バイナリファイルの追加

始める前に、すべての変更をコミットしたこと、作業ツリーが最新であること、およびインデックスにコミットされていない変更が含まれていないことを確認してください。災害が発生した場合に備えて、すべてのローカルブランチをリモート（githubなど）にプッシュすることをお勧めします。

1. 新しい孤立したブランチを作成します。git checkout --orphan binaryStuffトリックを行います。これにより、他のブランチから完全に切断されたブランチが生成されます。このブランチで行う最初のコミットには親がなく、ルートコミットになります。
2. を使用してインデックスをクリーンアップしますgit rm --cached * .gitignore。
3. 深呼吸して、を使用して作業ツリー全体を削除しrm -fr * .gitignoreます。ワイルドカードが一致しない.gitため、内部ディレクトリは変更され*ません。
4. VeryBigBinary.exeまたはVeryHeavyDirectory /にコピーします。
5. 追加してコミットします。
6. これはトリッキーになります-ブランチとしてリモートにプッシュすると、すべての開発者は次にgit fetch接続を妨害するときに呼び出されてダウンロードします。これを回避するには、ブランチの代わりにタグをプッシュします。これは、同僚が入力する癖がある場合でも、帯域幅とファイルシステムのストレージに影響を与える可能性がありますgit fetch <remote> --tagsが、回避策として読み進めてください。どうぞgit tag 1.0.0bin
7. 孤立したタグをプッシュしますgit push <remote> 1.0.0bin。
8. 誤ってバイナリブランチをプッシュしないように、削除することができますgit branch -D binaryStuff。コミットは、ガベージコレクションの対象としてマークされません1.0.0bin。これを指す孤立タグは、コミットを存続させるのに十分だからです。

バイナリファイルのチェックアウト

1. 私（または私の同僚）は、VeryBigBinary.exeを現在の作業ツリーにチェックアウトする方法を教えてください。現在の作業ブランチがたとえばマスターである場合は、簡単にできますgit checkout 1.0.0bin -- VeryBigBinary.exe。
2. 孤立したタグを1.0.0binダウンロードしていない場合、これは失敗します。この場合、git fetch <remote> 1.0.0bin事前にダウンロードする必要があります。
3. をVeryBigBinary.exeマスターのに追加すると、.gitignoreチームの誰もが誤ってバイナリでプロジェクトの主要な履歴を汚染することがなくなります。

バイナリファイルを完全に削除する

ローカルリポジトリ、リモートリポジトリ、および同僚のリポジトリからVeryBigBinary.exeを完全に削除する場合は、次のことができます。

1. リモートの孤立したタグを削除する git push <remote> :refs/tags/1.0.0bin
2. 孤立したタグをローカルで削除します（参照されていない他のすべてのタグを削除します）git tag -l | xargs git tag -d && git fetch --tags。わずかな変更を加えてSO 1841341から取得。
3. git gcトリックを使用して、現在参照されていないコミットをローカルで削除します。git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@"。他の参照されていないコミットもすべて削除されます。SO 1904860から取得
4. 可能であれば、リモートでgit gcトリックを繰り返します。リポジトリをセルフホスティングしている場合は可能ですが、githubなどの一部のgitプロバイダーや一部の企業環境ではできない場合があります。リモートへのsshアクセスを提供しないプロバイダーでホスティングしている場合は、許可してください。プロバイダーのインフラストラクチャーが、参照されていないコミットをスイートタイムでクリーンアップする可能性があります。企業環境にいる場合は、リモートに週に1回程度収集するcronジョブのガベージを実行するようITにアドバイスできます。彼らがそうであるかどうかにかかわらず、あなたがあなたの同僚に常にではgit clone -b master --single-branch <url>なく常に勧める限り、帯域幅とストレージの点であなたのチームに影響を与えませんgit clone。
5. 古くなった孤立したタグを削除したいすべての同僚は、手順2〜3を適用するだけで済みます。
6. その後、バイナリファイルの追加の手順1〜8を繰り返して、新しい孤立したタグを作成できます2.0.0bin。同僚が入力git fetch <remote> --tagsするのが心配な場合は、実際にもう一度名前を付けることができます1.0.0bin。これにより、次回すべてのタグをフェッチするときに、古いタグは1.0.0bin参照されなくなり、後続のガベージコレクション用にマークされます（手順3を使用）。リモートでタグを上書きしようとすると、次のように使用する必要があります-f。git push -f <remote> <tagname>

あとがき

• OTABSはマスターやその他のソースコード/開発ブランチには触れません。コミットハッシュ、すべての履歴、およびこれらのブランチの小さなサイズは影響を受けません。ソースコードの履歴が既にバイナリファイルで肥大化している場合は、別の作業としてクリーンアップする必要があります。このスクリプトは役に立つかもしれません。

• git-bashを使用してWindowsで動作することを確認しました。

• バイナリファイルの保存をより効率的にするために、一連の標準的なトリックを適用することをお勧めします。頻繁にgit gc（追加の引数なしで）実行すると、gitはバイナリデルタを使用してファイルの基本的なストレージを最適化します。ただし、ファイルがコミットからコミットまで似たままになる可能性が低い場合は、バイナリデルタを完全にオフに切り替えることができます。さらに、.zip、.jpg、.cryptなどのすでに圧縮または暗号化されたファイルを圧縮しても意味がないため、gitを使用すると、基になるストレージの圧縮をオフに切り替えることができます。残念ながら、これはソースコードにも影響するオールオアナッシング設定です。

• OTABSの一部をスクリプト化して、より迅速に使用できるようにすることができます。特に、バイナリファイルをupdategitフックに完全に削除するステップ2〜3をスクリプト化すると、git fetch（「古くなっているものをすべてフェッチして削除する」）に説得力のある、しかしおそらく危険なセマンティクスが与えられる可能性があります。

• 中央リポジトリの肥大化を犠牲にして、リモートでのすべてのバイナリ変更の完全な履歴を保持するために、バイナリファイルを完全に削除するステップ4をスキップすることができます。ローカルリポジトリは、時間の経過とともに無駄がなくなります。

• Javaの世界では、このソリューションを組み合わせmaven --offlineて、バージョンコントロールに完全に保存された再現可能なオフラインビルドを作成することができます（Mavenを使うとGradleよりも簡単です）。Golangの世界では、このソリューションに基づいてGOPATHを管理する代わりにGOPATHを管理することが可能ですgo get。Pythonの世界では、これをvirtualenvと組み合わせて、すべてのビルドを最初からPyPiサーバーに依存することなく、自己完結型の開発環境を作成できます。

• あなたのバイナリファイルは、ビルドの成果物のような、非常に頻繁に変更すると、それが解決孤児タグに格納アーティファクトの5つの最新バージョンをスクリプトには良い考えかもしれませんmonday_bin、tuesday_bin、...、friday_binリリースごとに、また孤児タグ1.7.8bin 2.0.0binなどweekday_bin。毎日、古いバイナリをローテーションして削除できます。このようにして、2つの世界のベストを利用できます。ソースコードの履歴はすべて保持しますが、バイナリ依存関係の関連する履歴のみを保持します。また、すべての履歴を含むソースコード全体を取得せずに、特定のタグのバイナリファイルを取得することも非常に簡単git init && git remote add <name> <url> && git fetch <name> <tag>です。

あなたがそうなら、私の意見では、多くの場合、これらの大きなファイルを修正するか、の多くを作成する予定がある場合にしますgit cloneか、git checkout、あなたが真剣に（それらのファイルにアクセスするための別の方法をまたは多分）別のGitリポジトリを使用することを検討すべきです。

しかし、私たちのように作業し、バイナリファイルが頻繁に変更されない場合、最初のクローン/チェックアウトは長くなりますが、その後は望みの速度になるはずです（ユーザーが最初のクローンリポジトリを使い続けることを考えると、持っていました）。

SVNはGitよりも効率的にバイナリデルタを処理するようです。

ドキュメント（JPEGファイル、PDFファイル、.odtファイル）のバージョン管理システムを決定する必要がありました。私はJPEGファイルを追加し、90度4回回転させてテストしました（バイナリデルタの効果を確認するため）。Gitのリポジトリは400％増加しました。SVNのリポジトリはわずか11％増加しました。

したがって、SVNはバイナリファイルの方がはるかに効率的です。

したがって、私の選択は、ソースコードにはGit、ドキュメントなどのバイナリファイルにはSVNです。

git clone --filter Git 2.19から+浅いクローン

この新しいオプションは、GitとGitHubが十分にユーザーフレンドリーにする場合、最終的にバイナリファイルの問題の最終的な解決策になる可能性があります（たとえば、サブモジュールではおそらくまだ達成されていません）。

実際にサーバーに必要なファイルとディレクトリのみをフェッチすることができ、リモートプロトコル拡張とともに導入されました。

これにより、最初に浅いクローンを作成し、次に、ビルドの種類ごとに、ビルドシステムでフェッチするblobを自動化できます。

--filter=blob:limit<size>フェッチする最大blobサイズを制限できるaもすでにあります。

機能がどのように見えるかの最小限の詳細な例を提供しました：Gitリポジトリのサブディレクトリのみを複製するにはどうすればよいですか？

私のソースコード（Webアプリケーション）が依存している大きなバイナリファイルを処理する方法についての意見を探しています。これに関するあなたの経験/考えは何ですか？

私は個人的に実行したGitリポジトリとの同期の失敗私のWebアプリケーションのバイナリデータは切り欠きたら私のクラウドホストの一部で3ギガバイトマークの上に。当時はBFT Repo Cleanerを検討していましたが、ハックのように感じました。それ以来、ファイルの管理、バージョン管理、バックアップにAmazon S3などの専用ツールを利用する代わりに、Gitの範囲外にファイルを保管するようになりました。

誰かが複数のGitリポジトリを使い、1つのプロジェクトでそれらを管理した経験はありますか？

はい。Hugoテーマは主にこの方法で管理されます。それは少しぎこちないですが、それは仕事を成し遂げます。

私の提案は、仕事に適したツールを選択することです。それが企業向けで、GitHubでコードラインを管理している場合は、お金を払ってGit-LFSを使用します。それ以外の場合は、ブロックチェーンを使用して分散型の暗号化されたファイルストレージなどのより創造的なオプションを探索できます。

考慮すべき追加のオプションには、Minioとs3cmdがあります。

見ていcamlistoreを。これは実際にはGitベースではありませんが、あなたがしなければならないことにはより適切だと思います。