Gemfile.lockを.gitignoreに含めるべきですか？
私はバンドラーとそれが生成するファイルにちょっと不慣れです。私はGitHubからのgitリポジトリのコピーを持っていて、それが多くの人々によって提供されているので、bundlerがリポジトリに存在せず.gitignoreリストにないファイルを作成したことに驚きました。
私はそれをフォークしたので、それをリポジトリに追加してもメインリポジトリに何も壊れないことは知っていますが、プルリクエストを実行した場合、それは問題を引き起こすでしょうか？
Gemfile.lockをリポジトリに含めるべきですか？
あなたがrubygemを書いていないと仮定すると、Gemfile.lockはあなたのリポジトリにあるはずです。それはあなたが必要とするすべての宝石とそれらの依存関係のスナップショットとして使われます。このようにして、あなたがデプロイするたびに、Bundlerはすべてのgem依存関係を再計算する必要はありません.
Cowboycodedのコメントから。
あなたが宝石に取り組んでいるならば、あなたのGemfile.lockをチェックインしないでください。
これがNice article ロックファイルとは何かを説明したものです。
実際の問題は、構成可能なデータベースアダプタを必要とするオープンソースのRailsアプリで作業しているときに起こります。私はFat Free CRMのRails 3ブランチを開発しています。私の好みはpostgresですが、デフォルトのデータベースはmysql2にします。
この場合、Gemfile.lockはまだgemのデフォルトセットでチェックインする必要がありますが、私は自分のマシンで行った変更を無視する必要があります。これを達成するために、私は実行します：
git update-index --assume-unchanged Gemfile.lock
そして逆にする：
git update-index --no-assume-unchanged Gemfile.lock
Gemfileに次のようなコードを含めると便利です。これはあなたのdatabase.ymlに基づいて適切なデータベースアダプタgemをロードします。
# Loads the database adapter gem based on config/database.yml (Default: mysql2)
# -----------------------------------------------------------------------------
db_gems = {"mysql2" => ["mysql2", ">= 0.2.6"],
"postgresql" => ["pg", ">= 0.9.0"],
"sqlite3" => ["sqlite3"]}
adapter = if File.exists?(db_config = File.join(File.dirname(__FILE__),"config","database.yml"))
db = YAML.load_file(db_config)
# Fetch the first configured adapter from config/database.yml
(db["production"] || db["development"] || db["test"])["adapter"]
else
"mysql2"
end
gem *db_gems[adapter]
# -----------------------------------------------------------------------------
これが確立されたベストプラクティスであるかどうかはわかりませんが、私にとってはうまくいきます。
私の同僚と私は異なるGemfile.lockを持っています。なぜなら私たちは異なるプラットフォーム、WindowsとMacを使用しており、そして私たちのサーバーはLinuxだからです。
Database.ymlと同じように、Gemfile.lockをrepoで削除し、Gemfile.lock.serverをgit repoで作成することにしました。それをサーバーにデプロイする前に、キャップデプロイフックを使用してGemfile.lock.serverをサーバー上のGemfile.lockにコピーします。
R-dubに同意してソース管理を続けますが、私にとって本当の利点はこれです。
同一環境での共同作業（windohsとlinux/macのことを無視して）。 Gemfile.lockが登場する前は、プロジェクトをインストールする次の人物は、あらゆる種類の混乱を招くようなエラーを見て、自分を責めるかもしれませんでしたが、彼は、スーパージェムの次のバージョンを手に入れ、既存の依存関係を壊しました。
さらに悪いことに、これはサーバ上で起こり、懲戒処分されていない限り正確なバージョンをインストールしてテストされていないバージョンを取得します。 Gemfile.lockはこれを明示的にしており、あなたのバージョンが異なることを明示的に教えてくれます。
注：：developmentや：testのように、ものをグループ化することを忘れないでください。
Bundlerのドキュメントでもこの問題に対処しています。
オリジナル： http://gembundler.com/v1.3/rationale.html
編集： http://web.archive.org/web/20160309170442/http://bundler.io/v1.3/rationale.html
「バージョン管理へのコードのチェックイン」というセクションを参照してください。
アプリケーションをしばらく開発した後、GemfileおよびGemfile.lockスナップショットと一緒にアプリケーションをチェックインします。これで、あなたのリポジトリには、あなたが最後にあなたがそのアプリケーションがうまくいったことを知っているときに使ったすべてのgemの正確なバージョンの記録があります。 Gemfileには3つの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がないということは、
- 奇妙なことが失敗するので、新しい貢献者はテストを実行することができません、それで彼らは貢献しないか、または失敗したPRを得ることができません…悪い最初の経験。
- ローカルのGemfile.lockを紛失した場合は、x歳のプロジェクトに戻ってプロジェクトを更新/書き換えせずにバグを修正することはできません。
- >常にGemfile.lockをチェックインし、さらに徹底的になりたい場合はtravisに削除させてください https://grosser.it/2015/08/14/check-in-your-gemfile-lock/ =
パーティーには少し遅れましたが、答えはまだ私にこの問題を理解するために時間と外国人の読書を要しました。それで、私はGemfile.lockについて私が見つけたことを要約したいです。
あなたがRailsアプリケーションを構築しているとき、あなたはあなたのローカルマシンでgemの特定のバージョンを使用しています。プロダクションモードや他のブランチでのエラーを回避したい場合は、Gemfile.lockファイルをいたるところで使用し、変更があるたびにgemを再構築するためにbundlerにbundleを指定する必要があります。
実稼働マシンでGemfile.lockが変更されていて、Gitがgit pullを許可していない場合は、そのファイルの変更を回避するためにgit reset --hardを書き、git pullをもう一度書く必要があります。