画像をgitリポジトリに保存する必要がありますか？

バージョン管理としてGitとGithubを使用する分散チームの場合、画像もgitリポジトリに保存する必要がありますか？

ほとんどの場合、画像は変更されません。それらを含むフォルダーは、画像が追加されるとサイズが大きくなります。懸念事項は、大きな画像の組み合わせ、またはそれらの多くだけで、画像フォルダが時間とともに大きくなる可能性があることです。

これはベストプラクティスと見なされますか？分散チームが簡単にアクセスできるプロジェクトで必要なバイナリファイルを共有するために、他にどのような方法がありますか？

あなたの画像は元の作品ですか、それとも他の場所から復元することができますか？ソースから構築されたソフトウェアユニットを出荷する必要がありますか？オリジナルの場合、バックアップが必要です。変更しない場合、スペースのペナルティはバックアップと同じであり、必要な場所にあります。

誤ってまたは意図的にソフトウェアの外観を変更するために編集できますか？はい-その後、それらは何らかの形でリビジョン管理される必要があります。すでに完全なソリューションがある場合は、別の方法を使用する必要があります。暗黒時代の「コピーと名前変更」バージョン管理を導入する理由

グラフィックデザイナーのMacBookハードドライブが死んだとき、プロジェクト全体の元のアートワークが「偽造」されるのを見ました。無限の知恵を持つ誰かが「バイナリは回転制御に属さない」と判断したためです。 ）バックアップには向かない傾向があります。

上記の基準に適合するすべてのバイナリファイルにも同じことが当てはまります。

しない唯一の理由は、ディスク容量です。言い訳が少し薄いので、1テラバイトあたり100ドルが怖い。

なぜ地獄ではないのですか？:)

バイナリを保存することは悪い習慣と見なされます、はい、しかし、私は画像についてあまり心配しません。

最悪の場合、トンがある場合は、それらを別の場所に保存するか、バイナリサポート用のエクスターナルまたは拡張機能を使用します。画像がそれほど頻繁に変更されない場合、問題はどこにありますか？あなたは大きな脂肪デルタを取得しません。そして、それらが時間の経過とともに削除された場合、履歴を保存することで少し苦しむのはあなたのサーバーだけですが、クライアントは何も見えません。

私の意見では、あなたはそれについて心配するべきではありません-あなたがそれらのGBを保存しないことを認めました。

あなたは何ができけれども行う、唯一の店「ソース」の画像です：SVGs、LaTeXのマクロ、等...とビルドシステムによって生成され、最終的なイメージがあります。可能であれば、おそらくさらに良いでしょう。そうでない場合は、気にしないでください。

（とはいえ、Gitはテキストファイルには適していますが、写真に最適なVCSではありません。可能であれば、コンテキストとメトリックを追加してください）

詳細については、次のQ＆Aをご覧ください。

• SubVersion / Gitに画像ファイルを保存する
• 非テキストファイルでのGitとSVN
• GitおよびGit-submoduleを使用した大きなバイナリファイルの管理

この質問はかなり古いですが、これは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を保存するだけなので、含まれるプロジェクトをクローンする他の開発者（」スーパープロジェクト」）は、すべてのサブモジュールを同じリビジョンで簡単に複製できます。スーパープロジェクトの部分的なチェックアウトが可能です。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つの答えは、サブモジュールを使用することです。これは、プロジェクトと画像間のリンクが弱くなることを意味します。したがって、画像をソースの一部であるかのように管理する必要はありませんが、制御されたままであり、サブプロジェクトが通常の開発プロセス中に同じチャーンを通過しないデータの単なる「フラットな」リポジトリであると仮定すると、それらのブランチの心配があります。

他の答えは、それらを別のプロジェクトに入れて、決して分岐させず、そのプロジェクトにコミットする全員がすぐにそれを上流にプッシュすることです-2人が同じバージョンのファイルを変更することは決してありません-あなたはこれが最も難しいとわかりますgitとしてのアスペクトは、そのような非分散型のワークフロー向けには設計されていません。このルールを施行するには、昔ながらの通信方法を使用する必要があります。

3番目の答えは、イメージの操作に適した別のSCMに完全に配置することです。

@haylemの答えに加えて、サイズがこの点で大きな要因になることに注意してください。VCSによっては、大量の画像でうまく機能しない場合があります。クローンや大規模なプッシュが一晩中かかり始めると、すべてのイメージがすでにリポジトリにあるため、本当に遅すぎます。

大きな写真と将来の成長を計画します。このプロジェクトに2年を費やしたくはありませんし、「レポが少し大きすぎるかもしれません。」

それらを技術的および経済的に保管することが実現可能であることに私は間違いなく同意します。質問「これらの画像は出荷製品の一部ですか、それとも出荷製品のコンテンツの一部ですか？」GIT（または他のVCS）にコンテンツを保存できないことではなく、別のVCSにとっては別の問題です。