似乎在开发机器上（比如在 Macbook 上），如果我们使用bundle install --deployment，所有的 gem 都将安装到vendor/bundle文件夹中，如果我们有多个 Rails 3 项目（一些项目只是为了测试 Rails 3），它只会使用更多的磁盘空间。如果不是--deployment，则 gem 将位于“通用”文件夹中，而不是在项目文件夹中，因此可以跨项目共享。这是真的？
另一件事是，我们是否需要将所有文件添加vendor/bundle到我们的存储库并推送它？似乎如果我们这样做，我们只是堵塞了 repo，因为如果我们不这样做，所有适当的 gem 将通过bundle install使用指定的所有gem 来安装Gemfile.lock。（这Gemfile.lock是回购中的一个小文件）。这也是真的吗？
当您使用该--deployment标志时，Bundler 会确保您需要的每个 gem都已售出，即它们被复制到您的应用程序文件夹结构的预定位置（按照惯例，这恰好vendor/bundle在 Rails 中）这有两个好处。
首先，如果您的权限有限，无法在部署机器中安装 gem，那么让您拥有应用程序中所需的所有 gem。
其次，如果您想破解 gems 中的实际代码，您可以在您出售的副本上这样做，而不会影响系统 gems。您所做的更改只会影响您正在处理的应用程序。
这种供应商方法曾经有另一种用途，即确保您使用的是特定版本的 gem，并且即使系统 gem 升级到会破坏您的应用程序的更高版本，您的应用程序也能继续工作。然而，Bundler 本身使这个用例大部分过时了，因为它自动安装和引用特定版本的 gem。
是的，供应商会使您的应用程序代码膨胀。Gemfile.lock只是所需宝石的列表。如果您出售您的宝石，它们会被竭尽全力复制到您的应用程序中。
因此，我建议您不要出售您的宝石（这也意味着不要使用--deployment标志），除非您有上述原因之一。
我认为供应商/捆绑包不会影响 repo，只要 repo 允许您忽略文件。
可以忽略它（.gitignore如果您使用的是 git，则添加路径）并且在服务器上有一个符号链接来共享具有多个修订的 gem。