533

ソース コード (Web アプリケーション) が依存する大きなバイナリ ファイルの処理方法について意見を求めています。現在、いくつかの代替案について話し合っています。

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

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

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

ファイルは、それらのファイルを含む PDF を生成するプログラムの画像です。ファイルは頻繁に変更されることはありません (数年単位) が、プログラムとの関連性は非常に高いものです。ファイルがないとプログラムは動作しません。

4

12 に答える 12

313

最近、素晴らしいと思うgit-annexを発見しました。大きなファイルを効率的に管理するために設計されました。写真/音楽 (など) のコレクションに使用します。git-annex の開発は非常に活発です。ファイルのコンテンツは Git リポジトリから削除できます。ツリー階層のみが Git によって (シンボリック リンクを通じて) 追跡されます。ただし、ファイルの内容を取得するには、プル/プッシュの後に次の手順が必要です。

$ 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

利用可能なコマンドは多数あり、Web サイトには優れたドキュメントがあります。パッケージはDebianで入手できます。

于 2011-07-09T13:54:28.817 に答える
177

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

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

これは、Git Bookのサブモジュールの優れた紹介です。

于 2009-02-12T14:29:01.293 に答える
54

2015 年 4 月以降の別のソリューションは、Git Large File Storage (LFS) (GitHub による) です。

これはgit-lfs ( git-lfs.github.comを参照) を使用し、それをサポートするサーバーでテストされています: lfs-test-server :
メタデータは git リポジトリにのみ保存でき、大きなファイルは別の場所に保存できます。

https://cloud.githubusercontent.com/assets/1319791/7051226/c4570828-ddf4-11e4-87eb-8fc165e5ece4.gif

于 2015-04-09T05:53:54.583 に答える
34

大きなバイナリをGitリポジトリにスマートに保存するためのGit拡張機能であるgitbupをご覧ください。

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

私は実際にこれ以上の圧縮率を見たことがありませんが、私のリポジトリにはそれほど大きなバイナリがありません。

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

于 2011-03-21T21:59:54.367 に答える
26

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

私は数ヶ月前に非常によく似た問題を抱えていました: ~21 GB の MP3 ファイル、分類されていない (名前が悪い、id3 が悪い、その MP3 ファイルが好きかどうかわからない...)、3 台のコンピューターに複製されました。

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

最終的に、MP3 ファイルは最大 6 GB、.git ディレクトリには最大 83 GB しかありませんでした。git-write-treeおよびを使用しgit-commit-treeて、コミットの先祖なしで新しいコミットを作成し、そのコミットを指す新しいブランチを開始しました。そのブランチの「git ログ」には、コミットが 1 つしか表示されませんでした。

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

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

于 2009-02-12T14:52:57.070 に答える
13

私の意見では、これらの大きなファイルを頻繁に変更する可能性がある場合、またはを大量に作成する場合は、git clone別git checkoutのGitリポジトリ（またはこれらのファイルにアクセスする別の方法）の使用を真剣に検討する必要があります。

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

于 2009-02-12T09:12:02.223 に答える
9

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

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

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

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

于 2010-10-03T03:11:41.550 に答える
0

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

于 2014-10-03T10:36:05.507 に答える