開発マシン (Macbook など) で を使用するbundle install --deploymentと、すべての gem がvendor/bundleフォルダーにインストールされ、複数の Rails 3 プロジェクト (Rails 3 をテストするためだけのプロジェクト) がある場合は、より多くのディスク容量が使用されるようです。そうでない場合--deployment、gem はプロジェクト フォルダー内ではなく "generic" フォルダーにあるため、プロジェクト間で共有できます。これは本当ですか？
もう 1 つは、すべてのファイルをvendor/bundleリポジトリに追加してプッシュする必要があるかどうかです。そうしないと、bundle install指定されたすべてのgemを使用して、適切なすべてのgemがインストールされるため、リポジトリを詰まらせるだけのようGemfile.lockです。(Gemfile.lockレポ内の小さなファイルです)。これも本当ですか？
フラグを使用すると--deployment、Bundler は必要なすべての gem がベンダー化されていることを確認します。つまり、アプリケーションのフォルダー構造 (vendor/bundle慣習により Rails 内にあります) にコピーされます。これには 2 つの利点があります。
まず、デプロイメント マシンに gem をインストールできない制限されたアクセス許可を持っている場合は、アプリ内で必要なすべての gem を使用できるようにします。
次に、gem 内の実際のコードをハッキングしたい場合は、システムの gem に影響を与えることなく、販売されているコピーをハックすることができます。行った変更は、作業中のアプリケーションにのみ影響します。
このベンダー アプローチには別の用途がありました。それは、特定のバージョンの gem を使用していることを確認することであり、システムの gem がアプリを破損させるより高いバージョンにアップグレードされた場合でも、アプリケーションは動作し続けます。ただし、Bundler 自体は、gem の特定のバージョンのインストールと参照を自動化するため、このユース ケースをほとんど廃止しました。
そうです、ベンダリングはアプリのコードを肥大化させます。Gemfile.lock必要な gem の単なるリストです。ジェムを販売すると、アプリに全力でコピーされます。
したがって、上記のいずれかの理由がない限り、gem を販売しない--deploymentことをお勧めします (フラグを使用しないことも意味します)。
リポジトリでファイルを無視できる限り、ベンダー/バンドルはリポジトリに影響を与えないと思います。それを無視して（ gitを使用している場合
はパスを追加して）、サーバー上に複数のリビジョンでgemを共有するためのシンボリックリンクがあります。.gitignore