Gemfile.lockを.gitignoreに含める必要がありますか？

私は、バンドラーとそれが生成するファイルのようなものです。私はGitHubからのgitリポジトリのコピーを持っていますが、これは多くの人から提供されているので、バンドルがリポジトリに存在せず、.gitignoreリストにもないファイルを作成したことに驚いていました。

私はそれをフォークしたので、それをリポジトリに追加してもメインリポジトリの何も壊れないことはわかっていますが、プルリクエストを実行すると問題が発生しますか？

Gemfile.lockリポジトリに含める必要がありますか？

rubygemを作成していないとすると、Gemfile.lockはリポジトリにあるはずです。必要なすべての宝石とその依存関係のスナップショットとして使用されます。このように、バンドルする人は、デプロイするたびにすべてのgem依存関係を再計算する必要がありません。

以下のcowboycodedのコメントから：

gemで作業している場合は、Gemfile.lockをチェックインしないでください。Railsアプリで作業している場合は、Gemfile.lockをチェックインしてください。

ロックファイルとは何かを説明する素晴らしい記事があります。

実際の問題は、構成可能なデータベースアダプターが必要なオープンソースの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をリポジトリから削除し、Gemfile.lock.serverをgit repoに作成することにします。次に、サーバーにデプロイする前に、capデプロイフックを使用してGemfile.lock.serverをサーバーのGemfile.lockにコピーします。

r-dubに同意し、ソース管理に維持しますが、私にとっての本当の利点は次のとおりです。

同一環境でのコラボレーション（windohやlinux / macなどは無視）。Gemfile.lockの前に、プロジェクトをインストールする次の人物はあらゆる種類の混乱するエラーを目にし、自分自身を非難するかもしれませんが、彼は次のバージョンのsuper gemを入手して、既存の依存関係を壊す幸運な男でした。

さらに悪いことに、これはサーバー上で発生し、統制されていない限り、テストされていないバージョンが取得され、正確なバージョンがインストールされます。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を実行すると、bundleは必要なすべての依存関係をすでに持っていることを確認し、インストールプロセスをスキップします。

.bundleディレクトリ、またはその中のファイルをチェックインしないでください。これらのファイルは各特定のマシンに固有であり、バンドルインストールコマンドの実行間でインストールオプションを維持するために使用されます。

バンドルパックを実行している場合、バンドルに必要なGem（Git Gemではありません）がベンダー/キャッシュにダウンロードされます。Bundlerは、必要なすべてのGemがそのフォルダーに存在し、ソース管理にチェックインされている場合、インターネット（またはRubyGemsサーバー）に接続せずに実行できます。ソース管理リポジトリのサイズが大きくなるため、これはオプションのステップであり、お勧めできません。

Gemfile.lockがないということは、次のことを意味します。

• 新しいコントリビューターは、奇妙なことが失敗するためテストを実行できません。そのため、コントリビューターが貢献したり、失敗したPRを取得したりすることはありません。
• ローカルのGemfile.lockを紛失した場合、プロジェクトを更新または書き直さなくても、x年前のプロジェクトに戻ってバグを修正することはできません。

->常にGemfile.lockをチェックインし、徹底的にhttps://grosser.it/2015/08/14/check-in-your-gemfile-lock/

パーティーには少し遅れましたが、答えはまだ私にこの問題を理解するのに時間と外国の読書を要しました。だから私はGemfile.lockについて私が見つけたものを要約したいと思います。

Railsアプリをビルドするときは、ローカルマシンで特定のバージョンのgemを使用しています。プロダクションモードや他のブランチでのエラーを回避したい場合は、その1つのGemfile.lockファイルをどこでも使用しbundle、変更するたびにgemを再構築するようにbundlerに指示する必要があります。

場合はGemfile.lock、あなたの生産機械やGitの上で変更されたあなたはできませんgit pull、あなたが書くべきgit reset --hardそのファイルの変更や書き込みを避けるためにgit pullもう一度。