いまどきのRuby開発には欠かせないBundlerですが、Gemfile.lockの扱いを間違えると面倒なことになります。
Gemfile.lockの役割
使うべきgemのバージョンを書くのがGemfileですが、たいていの場合はgemの特定のバージョンまで指定しないので、実際に使うものには変動の余地が生じます。そして、bundleを実行すると、Gemfile.lockへ、実際に使うこととなるgemのバージョンが書き込まれます。
別のマシンへプロジェクトを移動することになっても、Gemfile.lockがあれば、全く同じGem環境を容易に再現することができます。
Gemfile.lockが…ないとき〜
逆に、GemfileだけでGemfile.lockがないと、新規インストールとして作動します。システムインストールで、想定したのより古いgemがすでにあるとうまくインストールできなかったり、逆に勝手に最新版のGemが入って、思わぬバグとなってしまうこともありえます。バージョン管理をする場合、基本的にはGemfile.lockを含めたほうがいいでしょう。
身動きできなくなったパターン
ただし、ローカル環境がWindows、リモート環境がLinux、というようなシチュエーションでは、バイナリありのgemだと入れるバージョンが異なってきうること、さらには片方だけ入れるgemが発生することもあって、Gemfile.lockを共有することができず、それぞれ別個に生成せざるを得なくなってしまっています。
さらに悪いことに、リモートサーバをAWSのElastic Beanstalkで生成していたため、サーバの変動ごとにGemfile.lockが生成されることとなり、Gemfileで指定しない場合、gemは常に最新版が呼ばれることとなってしまいました。そして、ちょうどtherubyracerがうまく動かない問題にぶち当たってしまうこととなりました。
リモート用のGemfile.lockを別系統で管理するような仕組みが必要なのは間違いないところですが、どうしたものか検討中です。