在开发应用程序一段时间后，将应用程序与 Gemfile 和 Gemfile.lock 快照一起检入。现在，您的仓库记录了您上次知道应用程序正常工作时使用的所有 gem 的确切版本。请记住，虽然您的 Gemfile 只列出了三个 gem（版本严格程度不同），但考虑到您依赖的 gem 的所有隐式要求，您的应用程序实际上依赖于数十个 gem。
这一点很重要：Gemfile.lock 使您的应用程序成为您自己的代码和上次知道一切正常时运行的第三方代码的单个包。在您的 Gemfile 中指定您依赖的第三方代码的确切版本不会提供相同的保证，因为 gem 通常会为其依赖项声明一个版本范围。
下次您在同一台机器上运行 bundle install 时，bundler 会发现它已经拥有您需要的所有依赖项，并跳过安装过程。
不要检入 .bundle 目录或其中的任何文件。这些文件特定于每台机器，用于在 bundle install 命令的运行之间持久化安装选项。
如果您已经运行了 bundle pack，则您的捆绑包所需的 gem（虽然不是 git gem）将被下载到 vendor/cache 中。如果所有需要的 gem 都存在于该文件夹中并检入到您的源代码控制中，则 Bundler 可以不连接到互联网（或 RubyGems 服务器）运行。这是一个可选步骤，不建议这样做，因为这会增加源代码控制仓库的大小。
当您的协同开发人员（或您在另一台机器上）检出您的代码时，它将包含您上次开发时使用的所有第三方代码的精确版本（在 Gemfile.lock 中）。当他们运行 bundle install 时，bundler 会找到 Gemfile.lock 并跳过依赖项解析步骤。相反，它将安装您在原始机器上使用的所有相同 gem。
换句话说，您不必猜测应该安装哪些版本的依赖项。在我们一直在使用的示例中，即使 rack-cache 声明对 rack >= 0.4 的依赖关系，我们也确切地知道它与 rack 1.5.2 兼容。即使 Rack 团队发布了 rack 1.5.3，bundler 也会始终安装 1.5.2，即我们知道有效的 gem 的确切版本。这减轻了应用程序开发人员的大量维护负担，因为所有机器始终运行完全相同的第三方代码。