画像はgitリポジトリに保存する必要がありますか？
GitとGithubをバージョン管理として使用する分散チームの場合、画像もgitリポジトリに保存する必要がありますか？
ほとんどの場合、画像は変更されません。画像が追加されると、それらを含むフォルダのサイズが大きくなります。懸念されるのは、大きな画像を組み合わせたり、大量の画像を組み合わせたりすることで、時間の経過とともに画像フォルダが大きなサイズになる可能性があることです。
これはベストプラクティスと見なされますか？分散チームが簡単にアクセスできるプロジェクトで必要なバイナリファイルを共有する他の方法はありますか？
画像はオリジナルの作品ですか、それとも他の場所から復元できますか？ソースから構築されたソフトウェアユニットを出荷する必要がありますか？オリジナルの場合は、バックアップが必要です。それらをリビジョン管理に入れてください。変更されない場合、スペースのペナルティはバックアップと同じであり、必要な場所にあります。
それらを編集して、ソフトウェアの外観を誤ってまたは意図的に変更できますか？はい-そして、それらはどういうわけかリビジョン管理されている必要があります、なぜあなたがすでに完璧なソリューションを持っているときに別の方法を使うのですか？暗黒時代から「コピーして名前を変更する」バージョン管理を導入する理由
グラフィックデザイナーのMacBookハードドライブが死んだとき、プロジェクト全体のオリジナルのアートワークが「不審」になるのを見てきました。これは、無限の知識を持つ誰かが「バイナリは回転制御に属さない」と判断したためです。グラフィックデザイナー（少なくともこれは）バックアップに適している傾向はありません。
上記の基準を満たすすべてのバイナリファイルにも同じことが当てはまります。
しない唯一の理由は、ディスク容量です。恐らく100ドル/テラバイトですが、その言い訳は少し薄いです。
なぜ地獄ではないのですか？ :)
バイナリを保存することは悪い習慣だと考えられます、しかし、私は画像についてあまり心配しませんでした。
最悪の場合、トンがある場合は、別の場所に保管するか、バイナリサポート用の外部または拡張機能を使用してください。そして、画像がそれほど頻繁に変更されない場合、問題はどこにあるのでしょうか？あなたは大きな脂肪デルタを取得しません。そして、それらが時間の経過とともに削除された場合、履歴を保存するのに少し苦労しているのはサーバーだけですが、クライアントには何も表示されません。
私の意見では、あなたはそれについて心配するべきではありません-あなたがそれらのGBを保存しないことを認めます。
あなたができることは、「ソース」イメージ（SVG、LaTeXマクロなど）のみを格納し、ビルドによって最終イメージを生成するだけですシステム。可能であれば、それはおそらくさらに良いでしょう。そうでない場合は、気にしないでください。
（言われていることすべて、Gitはテキストファイルに最適ですが、画像に最適なVCSではありません。可能であれば、コンテキストとメトリックを増やしてください）
詳細については、次のQ＆Aをご覧ください。
この質問はかなり古いですが、これはGitを扱うときに出くわす一般的な質問であり、最後の回答以降、Gitリポジトリに大きなファイルを保存するための最新のソリューションにはいくつかの進歩があります。
大きなファイルをGitに保存するには、次のプロジェクトがあります。
- git-annex -これはしばらく前からありましたが、率直に言って、複雑さが邪魔になります。
- git-media -これでの個人的な経験はありません。同様にかなり複雑に思えます。
- git-fit -よりシンプルなプラグインを作成する試み。 S3ストレージが必要です。プラグインに関する私の主な懸念は、その単純さには感謝しますが、プラグインはかなり知られておらず、1人の個人によって管理されているということです（完全な開示、現時点では私が唯一のコミッターであり、些細な問題のためでした）。
- git-lfs -これを広範囲に使用したことはありませんが、これは聖杯のようです。これはGithubによってサポートされており、2015年10月現在、すべてのリポジトリで 利用可能であり 、リポジトリを保存するサイトでのファイル管理の複雑さを考慮しています。唯一の欠点は、これがかなり新しいということです。したがって、Githubを超えるサポートはほとんどありませんが、 Gitlabもサポートしています 、 Giteaと同様です 、 Bitbucketは将来サポートすることを暗示しています 。
TLDR：可能であれば、 git-lfs を使用して画像または他のバイナリファイルをgitに保存します
「バイナリをソース管理に保存しない」全体は、特定の理由で説明されています。コンパイルするソースコードがある場合、実際のコンパイルは保存せず、ソースコードのみを保存します。画像とビジュアルアセットには「ソース」がないため、バージョン管理でそれらを追跡する必要があります。
Gitでの推奨される方法は、基本的にメインのリポジトリに関連付けられている個別のリポジトリであるサブモジュール（Git 1.5.3で導入）を使用することだと思います。画像（およびその他のバイナリアセット）をサブモジュールに保存します。これは、必要なものに応じて、メインリポジトリでチェックアウトするか、そのままにすることができます。
から http://book.git-scm.com/5_submodules.html
「Gitのサブモジュールサポートにより、リポジトリにサブプロジェクトとして外部プロジェクトのチェックアウトを含めることができます。サブモジュールは独自のIDを維持します。サブモジュールサポートはサブモジュールリポジトリの場所とコミットIDを保存するだけなので、含まれているプロジェクトを複製する他の開発者（ " superproject "）は、同じリビジョンのすべてのサブモジュールのクローンを簡単に作成できます。スーパープロジェクトの部分的なチェックアウトが可能です。サブモジュールの一部またはすべてをクローンしないようにGitに指示できます。"
また、画像が頻繁に変更されない場合、サイズは重要な問題ではありません。次のようなコマンドを実行して、サイズを削減/縮小することもできます。
git gc
git gc-aggressive
git Prune
はい。
ソフトウェアバージョン1.0をリリースするとします。バージョン2.0の場合は、すべての画像をシャドウ付きでやり直すことにしました。つまり、これを行い、2.0をリリースします。次に、1.0を使用していて2.0にアップグレードできない顧客が、プログラムを別の言語で使用することを決定します。彼らはあなたにそれをするために1Gを与えるので、あなたは確かに言う。しかし、異なる文化では、一部の写真が意味をなさないため、それらを変更する必要があります...
画像をソース管理で保持する場合、これは簡単です。1.0に基づいて、（特に）画像に変更を加え、ビルド、リリースします。ソース管理にこれらがない場合は、古いイメージを見つけて変更し、ビルドする必要があるため、はるかに困難になります。
プロジェクトの一部である場合、VCSに存在する必要があります。これを最良に達成する方法は、VCS、またはプロジェクトの編成方法によって異なります。多分デザイナーのためのレポ、そしてコーダーのレポの結果のみ、または '画像ソース'のみ（私はかつて.svgファイルのみのプロジェクトと、make/inscape cliを介して生成された画像）を持っています。
しかし、VCSがそれを処理できないか、使用できなくなった場合、それはあなたの仕事に適したツールではないと思います。
これまでのところ、私はgitにWebプロジェクトの「通常」の量のグラフィック（モックアップ、コンセプト、ページグラフィック）を配置することに問題はありませんでした。
画像をSCMに保存する必要があります：はい。間違いありません。
画像をgitに保存する必要がある場合：これはよりトリッキーになります。
gitはテキストファイルで非常に優れていますが、その性質上、バイナリではそれほど熱くなりません。クローンまたはプッシュするときに転送されるデータのサイズに問題が発生し、.gitディレクトリが大きくなり、マージで混乱が生じる可能性があります（つまり、2つのイメージをどのようにマージするか！）
1つの答えは、サブモジュールを使用することです。これは、プロジェクトとイメージ間のリンクが弱くなることを意味します。そのため、イメージをソースの一部であるかのように管理する必要はありませんが、それでもイメージを制御したままにし、それらの分岐に関する心配-サブプロジェクトが通常の開発プロセス中に同じチャーンを通過しないデータの「フラットな」リポジトリであると仮定します。
もう1つの答えは、それらを別のプロジェクトに配置し、決して分岐せず、そのプロジェクトにコミットするすべての人がすぐにプロジェクトを上流にプッシュすることです。2人が同じバージョンのファイルを変更しないようにしてください。これが最も難しいと感じるでしょう。 gitはこのような非分散型ワークフロー用に設計されていないため、このルールを適用するには、昔ながらの通信方法を使用する必要があります。
3番目の答えは、画像を操作するのに適した別のSCMにそれらを完全に配置することです。
@haylemの答えに加えて、サイズがこれに大きな要因を果たしていることに注意してください。 VCSによっては、大量の画像を処理できない場合があります。クローンまたは大規模なプッシュが一晩かかり始めると、すべてのイメージがすでにリポジトリにあるため、本当に手遅れです。
大きな画像と将来の成長を計画します。あなたはこのプロジェクトに2年間は入りたくないし、「おおおおおおおおおおおおおおおおおおおおおおおおお使積みせありしさささ、たぶん、レポは少しtoo大きい」。
技術的および経済的にそれらを保存することは可能であることに私は間違いなく同意します。質問「これらの画像は、出荷製品の一部ですか、それとも出荷製品のコンテンツの一部ですか？」 GIT（またはその他のVCS）にコンテンツを保存することはできませんが、それは別のVCSにとっては別の問題です。