しばらくアプリケーションを開発したあと、GemfileとGemfile.lockのスナップショットと一緒にアプリケーションをチェックインします。これで、アプリケーションが確実に機能した最後の瞬間にすべて利用したgemの正確なすべてのバージョンに関するリコードがリポジトリに記録されます。Gemfileには3つのgemのみ（バージョン厳密度の違いによる）がリストされていることを覚えておいてください。依存するすべてのgemの暗黙的な要件を加味すると、このアプリケーションは何十ものgemに依存していることになります。
この点が重要です。Gemfile.lockは、アプリケーションを独自のコードと、最後にすべてが期待通りに機能したときに実行したサードパーティのコードを組み合わせた単一のパッケージにします。Gemfileで依存するサードパーティのコードの正確なバージョンを指定しても、同じ保証は得られません。通常、gemは依存関係に対してバージョン範囲を宣言するためです。
同じマシンでbundle installを再度実行すると、バンドラーは必要な依存関係をすべてすでに持っていることを認識して、インストール処理をスキップします。
.bundleディレクトリやその中のファイルをすべてチェックインしないでください。これらのファイルは特定のマシンに固有で、bundle installコマンドの実行間でインストールオプションを永続化するために使用されます。
bundle packを実行した場合、バンドルに必要なgem（git gemは除く）がvendor/cacheにダウンロードされます。必要なすべてのgemがそのフォルダーに存在して、ソース制御にチェックインされていれば、バンドラーはインターネット（またはRubyGemsサーバー）に接続しなくても実行できます。これはオプションのステップで、ソース制御リポジトリのサイズが大きくなるため、推奨されません。
一緒に開発を行う開発者（または別のマシン上のあなた）がコードをチェックアウトすると、最後に開発を行ったマシン（Gemfile.lockの中）上のアプリケーションで利用されたすべてのサードパーティのコードのバージョンが正確に示されます。開発者が bundle installを実行すると、バンドラーはGemfile.lockを見つけて依存関係の解決ステップをスキップします。代わりに、元のマシンで利用したのと同じすべてのgemをインストールします。
言い換えると、インストールする依存関係のバージョンを推測する必要はありません。使用している例では、rack-cacheがrack >= 0.4への依存関係を宣言していますが、rack 1.5.2でも確実に機能することはわかっています。Rackチームがrack 1.5.3をリリースした場合でも、バンドラーは常に1.5.2（確実に機能することがわかっているgemの正確なバージョン）をインストールします。これにより、すべてのマシンが常にまったく同じサードパーティのコードを実行するため、アプリケーション開発者に大きな保守の負担を軽減できます。