bundle-install - 安装 Gemfile 中指定的依赖项
bundle install [--binstubs[=DIRECTORY]]
[--clean]
[--deployment]
[--frozen]
[--full-index]
[--gemfile=GEMFILE]
[--jobs=NUMBER]
[--local]
[--no-cache]
[--no-prune]
[--path PATH]
[--prefer-local]
[--quiet]
[--redownload]
[--retry=NUMBER]
[--shebang]
[--standalone[=GROUP[ GROUP...]]]
[--system]
[--trust-policy=POLICY]
[--with=GROUP[ GROUP...]]
[--without=GROUP[ GROUP...]]安装 Gemfile(5) 中指定的 gem。如果这是您第一次运行 bundle install（并且不存在 Gemfile.lock），Bundler 将获取所有远程源，解析依赖项并安装所有需要的 gem。
如果存在 Gemfile.lock，并且您没有更新 Gemfile(5)，Bundler 将获取所有远程源，但使用 Gemfile.lock 中指定的依赖项，而不是解析依赖项。
如果存在 Gemfile.lock，并且您更新了 Gemfile(5)，Bundler 将对您未更新的 gem 使用 Gemfile.lock 中的依赖项，但会重新解析您更新的 gem 的依赖项。您可以在下面 保守更新 部分找到有关此更新过程的更多信息。
--clean、--deployment、--frozen、--no-prune、--path、--shebang、--system、--without 和 --with 选项已弃用，因为它们只有在自动应用于每个后续 bundle install 运行时才有意义，而这需要 bundler 静默地记住它们。由于 bundler 在未来版本中将不再记住 CLI 标志，因此应使用 bundle config（参见 bundle-config(1)）来永久应用它们。
--binstubs[=<directory>]bin/ 中。这使您可以将 binstub 链接到应用程序内部，以使用应用程序所需的特定 gem 版本。
创建一个目录（默认为 ~/bin）并将 gem 中的任何可执行文件放在那里。这些可执行文件在 Bundler 的上下文中运行。如果使用，您可能需要将此目录添加到环境的 PATH 变量中。例如，如果 rails gem 带有一个 rails 可执行文件，则此标志将创建一个 bin/rails 可执行文件，确保所有引用的依赖项都将使用捆绑的 gem 进行解析。
--clean此选项已弃用，建议使用 clean 设置。
--deployment此选项已弃用，建议使用 deployment 设置。
--redownload--frozen此选项已弃用，建议使用 frozen 设置。
--full-index--gemfile=<gemfile>Gemfile.lock 和 vendor/cache。--jobs=[<number>], -j[<number>]
--localrubygems.org。相反，Bundler 将使用已存在于 Rubygems 缓存或 vendor/cache 中的 gem。请注意，如果 rubygems.org 上存在适当的平台特定 gem，则不会找到它。--prefer-localvendor/cache 中的 gem，即使远程存在更新的版本。仅尝试连接到 rubygems.org 以获取本地不存在的 gem。--no-cachevendor/cache 中的缓存。这不会删除缓存中的任何 gem，但会阻止新捆绑的 gem 在安装过程中被缓存。--no-prune此选项已弃用，建议使用 no_prune 设置。
--path=<path>gem install ... 也会将 gem 安装到此位置。因此，没有使用 --path ... 设置安装的 gem 将通过调用 gem list 显示。相应地，安装到其他位置的 gem 不会列出。
此选项已弃用，建议使用 path 设置。
--quiet$?) 退出。--retry=[<number>]--shebang=<ruby-executable>ruby）来执行使用 --binstubs 创建的脚本。此外，如果您将 --binstubs 与 --shebang jruby 一起使用，这些可执行文件将更改为执行 jruby。
此选项已弃用，建议使用 shebang 设置。
--standalone[=<list>]bundle 的目录并将 bundle 安装到该目录。它还会生成一个 bundle/bundler/setup.rb 文件，以替换 Bundler 自身的设置，以满足所需的方式。使用此选项会隐式设置 path，它是一个 [记住的选项][REMEMBERED OPTIONS]。--system--path 的任何配置。
此选项已弃用，建议使用 system 设置。
--trust-policy=[<policy>]HighSecurity、MediumSecurity、LowSecurity、AlmostNoSecurity 或 NoSecurity 之一。有关更多详细信息，请参阅下面 SEE ALSO 中链接的 Rubygems 签名文档。--with=<list>此选项已弃用，建议使用 with 设置。
--without=<list>此选项已弃用，建议使用 without 设置。
Bundler 的默认设置针对开发进行了优化。要切换到针对部署和 CI 优化的默认设置，请使用 --deployment 标志。不要在开发机器上激活部署模式，因为它会在修改 Gemfile(5) 时导致错误。
需要 Gemfile.lock。
为了确保在部署中使用与开发和测试时相同的 gem 版本，需要 Gemfile.lock。
这主要是为了确保您记得将 Gemfile.lock 提交到版本控制中。
Gemfile.lock 必须是最新的
在开发中，您可以修改您的 Gemfile(5) 并重新运行 bundle install 以 保守地更新 您的 Gemfile.lock 快照。
在部署中，您的 Gemfile.lock 应该与您在 Gemfile(5) 中所做的更改保持一致。
gem 安装到 vendor/bundle 而不是您的默认系统位置
在开发中，与系统上的其他应用程序和其他脚本共享应用程序中使用的 gem 很方便。
在部署中，隔离是一个更重要的默认设置。此外，部署应用程序的用户可能没有权限将 gem 安装到系统中，或者 Web 服务器可能没有权限读取它们。
因此，bundle install --deployment 将 gem 安装到应用程序的 vendor/bundle 目录中。这可以通过使用 --path 选项来覆盖。
默认情况下，bundle install 将安装 Gemfile(5) 中所有组中的所有 gem，除了为不同平台声明的 gem 之外。
但是，您可以明确地告诉 Bundler 使用 --without 选项跳过安装某些组。此选项接受一个用空格分隔的组列表。
虽然--without选项会跳过安装指定组中的 gem，但它仍然会下载这些 gem 并使用它们来解析 GemfileGemfile(5)中每个 gem 的依赖项。
这样做的目的是，在另一台机器（例如生产服务器）上安装不同的组集时，不会改变您已经开发和测试过的 gem 和版本。
Bundler 提供了一个坚如磐石的保证，即您在开发和测试中运行的第三方代码也是您在生产中运行的第三方代码。您可以选择在不同的环境中排除一些代码，但您永远不会因为在不同的环境中使用不同版本的第三方代码而措手不及。
为了简单说明，请考虑以下 GemfileGemfile(5)
source 'http://rubygems.org.cn'
gem 'sinatra'
group :production do
gem 'rack-perftools-profiler'
end
在这种情况下，sinatra 依赖于任何版本的 Rack（>= 1.0），而 rack-perftools-profiler 依赖于 1.x（~> 1.0）。
当您在开发环境中运行 bundle install --without production 时，我们也会查看 rack-perftools-profiler 的依赖项。这样，您就不会花所有时间针对 Rack 2.0 进行开发，使用 Rack 1.x 中不可用的新 API，只是在使用 production 组时，Bundler 切换到 Rack 1.2。
这在实践中不应该造成任何问题，因为我们不会尝试安装被排除的组中的 gem，并且只在依赖项解析过程中进行评估。
这也意味着您不能在不同的组中包含相同 gem 的不同版本，因为这样做会导致在开发和生产中使用不同的依赖项集。由于依赖项解析过程的复杂性，这通常会影响您在 GemfileGemfile(5)中列出的 gem 以外的更多内容，并且（令人惊讶地）会彻底改变您正在使用的 gem。
当您运行 bundle install 时，Bundler 会将您使用的所有 gem 的完整名称和版本（包括 GemfileGemfile(5)中指定的 gem 的依赖项）持久化到一个名为 Gemfile.lock 的文件中。
Bundler 在所有后续调用 bundle install 时使用此文件，这保证了你始终使用完全相同的代码，即使你的应用程序在机器之间移动。
由于依赖关系解析的工作方式，即使是看似很小的更改（例如，更新你 Gemfile(5) 中 gem 的依赖项的点版本）也会导致需要完全不同的 gem 来满足所有依赖项。
因此，你 应该 将你的 Gemfile.lock 检查到版本控制中，无论是在应用程序还是 gem 中。如果你不这样做，每个检出你的仓库的机器（包括你的生产服务器）都会再次解析所有依赖项，如果 Gemfile(5) 中的任何 gem 或其任何依赖项已更新，这将导致使用不同版本的第三方代码。
当 Bundler 首次发布时，Gemfile.lock 被包含在与生成的 gem 一起提供的 .gitignore 文件中。然而，随着时间的推移，很明显这种做法将破坏依赖项的痛苦强加于新的贡献者，而让现有的贡献者可能没有意识到这个问题。由于 bundle install 通常是贡献的第一步，破坏依赖项的痛苦会阻止新的贡献者做出贡献。因此，我们已经修改了对 gem 作者的指导，现在建议将 gem 的锁定检查进去。
当你对 Gemfile(5) 进行更改，然后运行 bundle install 时，Bundler 只会更新你修改的 gem。
换句话说，如果你 没有修改 的 gem 在你调用 bundle install 之前工作，它将继续使用与更新之前完全相同的依赖项版本。
让我们看一个例子。这是你最初的 Gemfile(5)
source 'http://rubygems.org.cn'
gem 'actionpack', '2.3.8'
gem 'activemerchant'
在这种情况下，actionpack 和 activemerchant 都依赖于 activesupport。actionpack gem 依赖于 activesupport 2.3.8 和 rack ~> 1.1.0，而 activemerchant gem 依赖于 activesupport >= 2.3.2、braintree >= 2.0.0 和 builder >= 2.0.0。
当依赖项首次解析时，Bundler 将选择 activesupport 2.3.8，它满足你 Gemfile(5) 中两个 gem 的要求。
接下来，您需要修改您的 Gemfile(5) 文件。
source 'http://rubygems.org.cn'
gem 'actionpack', '3.0.0.rc'
gem 'activemerchant'
actionpack 3.0.0.rc gem 包含许多新的依赖项，并且将 activesupport 依赖项更新为 = 3.0.0.rc，将 rack 依赖项更新为 ~> 1.2.1。
当您运行 bundle install 时，Bundler 会注意到您更改了 actionpack gem，但没有更改 activemerchant gem。它会评估当前正在使用的 gem 以满足其需求。
activesupport 2.3.8activemerchant 中的依赖项，而 activemerchant 并没有被更新。rack ~> 1.1.0由于您没有明确要求更新 activemerchant，因此您不会期望它在更新 actionpack 后突然停止工作。但是，满足 actionpack 的新 activesupport 3.0.0.rc 依赖项需要更新其依赖项之一。
即使 activemerchant 声明了一个非常宽松的依赖项，理论上与 activesupport 3.0.0.rc 匹配，Bundler 也会将您 Gemfile(5) 中没有更改的 gem 与其依赖项一起视为一个原子单元。在这种情况下，activemerchant 依赖项被视为 activemerchant 1.7.1 + activesupport 2.3.8，因此 bundle install 将报告它无法更新 actionpack。
要明确更新 actionpack，包括其依赖项（其他 Gemfile(5) 中的 gem 仍然依赖于这些依赖项），请运行 bundle update actionpack（参见 bundle update(1)）。
总结：一般来说，在对 Gemfile(5) 进行更改后，您应该首先尝试运行 bundle install，这将确保 Gemfile(5) 中的任何其他 gem 不会受到更改的影响。如果这不起作用，请运行 bundle update(1)。