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