私は主にJavaアプリケーションを構築している会社で働いており、SCMへのバイナリファイル（依存関係と最終製品）のチェックインを停止するようにみんなを説得しようとしています。
彼らはそれが悪い習慣であることを知っていますが、彼らは「それはうまくいく」と考え、多くの人がMavenやAnt以外のビルドのための他のツールについて知っていても、実際には問題ではありません。PMとプログラマー（約50人）のどちらも、反対意見に耳を傾け、バックアップスペースの浪費であることを認める用意がありますが、習慣の変化には多大な労力が伴うため、私は本当に納得したいと思います。変更をサポートするためにどのような議論を使用しますか？
編集：さて、依存関係のようなほとんど変化しないファイルと生成されたファイルを区別することは理にかなっています。それでも、後者に反対する理由に興味があります。
回答:
ストレージスペースは安価であるため、ファイルをチェックインする必要があるかどうかを確認する理由としては、それほど説得力のあるものではありません。
代わりに、SCMの目的にアピールできます。SCMによって追跡される各ファイルは、チームが行っている並行して分散された変更を管理する必要性を表しています。2人のチームメンバーが同じファイルを変更しようとするまで、それは本当に明らかではありません。これらの変更を解決することがSCMの本来の目的であり、別の開発者の作業が誤って上書きされるのを防ぎ、うまくいけば、それらの変更をマージするプロセスを自動化します。
ジェネリックマージツールがマージされたバイナリファイルがどのように機能するかを推測する正しい方法がないため、バイナリファイルをマージすることは通常、実際の課題です。特定のファイルタイプを認識するように特別に設計されていない限り、ファイル内のインデックスまたはオフセットポインターがどのように機能するかを十分に知ることはできません。
つまり、バイナリファイルを手動でマージし、ファイルが非常にマージされたことをSCMに伝えるのは開発者次第です。それは開発者であるので、マージは以前の両方のチェックインの変更のすべてを実際にはカバーしない可能性があり、ファイルはバイナリなので、マージを検証する自動化された方法はありません。
アートアセットなどのプロジェクトソースを実際に表すバイナリ形式の場合、これは残念ながら必要なステップです。ただし、ビルド出力はソースではありません。ソースをマージして、結果のビルド出力を再生成できるため、それらをマージする必要はありません。これらの変更の追跡と管理は100％無駄です。それほどではありませんが、SCMのリソースを浪費しますが、開発者が誤ったマージの失敗を乗り越える時間も浪費します。開発者の時間は非常に高く、それを無駄にするものはすべて癌です。
一方、ビルド出力をアーカイブする必要がある特定のケースがあります。これまでに出荷またはデプロイされたプロジェクトのバージョンは、おそらく無期限に保持する必要があります。顧客が問題を抱えている実際のビルドの正確なバイトごとのコピーがあると、顧客の正確なバージョンが得られるため、顧客のサポートがはるかに簡単になります。
それらのバックアップは通常、異なるスケジュールに従い、基本的に異なる構造を持つため、ソースコードと同じリポジトリにそのバックアップを置くべきではありません。
バイナリ形式であっても、依存関係をチェックインして、他の誰かがプロジェクトをプルダウンしたときに機能するようにします。主な関心事はファイルの種類ではなく、ファイルの作成方法です。私が使用する経験則では、別のファイルを使用して生成できる場合、チェックインされません。これは、自動生成されたドキュメント、作成したバイナリファイルなどを意味します。
SCMを使用する主な利点の1つは、過去のいつでもシステムを再構築できることです。したがって、リビジョン番号を確認してビルドするだけなので、最終ビルドをSCMに保存しても意味がありません。
依存関係について言及します... SCMは、（開発環境を備えた）新しいマシンにクリーンチェックアウトを実行し、ビルドをヒットできるようにセットアップする必要があります。他に何もインストールしなくてもシステムをビルドできるはずです。したがって、SCMでバイナリ依存関係を維持することは良い考えです。ライブラリはめったに変更されないため、あまり場所を取りません。
ほとんど誰もこれをしません。