私はbundlerとそれが生成するファイルに少し慣れていません。.gitignore多くの人から提供されているGitHubのgitレポジトリのコピーを持っているので、バンドラーがレポジトリに存在せず、リストに含まれていないファイルを作成したことに驚きました。
フォークしたので、レポに追加してもメインレポは壊れないのはわかっていますが、プルリクエストをすると問題が発生しますか？
Gemfile.lockリポジトリに含める必要がありますか？
107004 次
9 に答える
588
あなたがrubygemを書いていないと仮定すると、Gemfile.lockはあなたのリポジトリにあるはずです。これは、必要なすべてのgemとその依存関係のスナップショットとして使用されます。このように、バンドラーはデプロイするたびにすべてのgem依存関係を再計算する必要はありません。
以下のカウボーイコードのコメントから：
gemで作業している場合は、Gemfile.lockをチェックインしないでください。Railsアプリで作業している場合は、Gemfile.lockをチェックインしてください。
これは、ロックファイルとは何かを説明する素晴らしい記事です。
于 2010-11-11T05:13:08.407 に答える
52
実際の問題は、構成可能なデータベースアダプターが必要なオープンソースのRailsアプリで作業しているときに発生します。FatFreeCRMのRails3ブランチを開発しています。私の好みは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]
# -----------------------------------------------------------------------------
これが確立されたベストプラクティスであるかどうかはわかりませんが、私にとってはうまくいきます。
于 2011-03-19T04:39:21.203 に答える
37
異なるプラットフォーム、Windows、Macを使用しており、サーバーがLinuxであるため、同僚と私は異なるGemfile.lockを使用しています。
database.ymlと同様に、リポジトリでGemfile.lockを削除し、gitリポジトリでGemfile.lock.serverを作成することにしました。次に、サーバーにデプロイする前に、capdeployhookを使用してGemfile.lock.serverをサーバー上のGemfile.lockにコピーします。
于 2011-06-16T02:31:19.507 に答える
12
r-dubに同意し、ソース管理を維持しますが、私にとっての本当の利点は次のとおりです。
同一環境でのコラボレーション（windohsとlinux / macのものは無視）。Gemfile.lockの前に、プロジェクトをインストールする次の男は、自分を責め、あらゆる種類の紛らわしいエラーを目にするかもしれませんが、彼は、既存の依存関係を壊して、次のバージョンのスーパーgemを入手した幸運な男でした。
さらに悪いことに、これはサーバーで発生し、懲戒処分を受けて正確なバージョンをインストールしない限り、テストされていないバージョンを取得します。Gemfile.lockはこれを明示的にし、バージョンが異なることを明示的に通知します。
注：：developmentと：testのように、グループ化することを忘れないでください
于 2010-11-11T16:34:17.967 に答える
11
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が通常、依存関係のバージョンの範囲を宣言しているためです。
次回同じマシンでbundleinstallを実行すると、bundlerは必要なすべての依存関係がすでにあることを確認し、インストールプロセスをスキップします。
.bundleディレクトリまたはその中のファイルをチェックインしないでください。これらのファイルは特定のマシンごとに固有であり、bundleinstallコマンドの実行間でインストールオプションを永続化するために使用されます。
バンドルパックを実行した場合、バンドルに必要なgem（git gemではありません）がベンダー/キャッシュにダウンロードされます。必要なすべてのgemがそのフォルダーにあり、ソース管理にチェックインしている場合、Bundlerはインターネット（またはRubyGemsサーバー）に接続せずに実行できます。これはオプションの手順であり、ソース管理リポジトリのサイズが大きくなるため、お勧めしません。
于 2013-04-17T16:47:47.993 に答える
9
2021年の簡単な答え： Gemfile.lockはRubygemsのバージョン管理にも含まれている必要があります。受け入れられた答えは現在11歳です。
ここでいくつかの理由（コメントからチェリーを選んだ）：
@josevalim https://github.com/heartcombo/devise/pull/3147#issuecomment-52193788
寄稿者と開発者はプロジェクトをフォークし、動作が保証されているバージョンを使用して実行できる必要があるため、Gemfile.lockはリポジトリにとどまる必要があります。
@rafaelfranca https://github.com/rails/rails/pull/18951#issuecomment-74888396
プラグインの場合でも、ロックファイルを無視するのは良い考えではないと思います。
これは、数十の依存関係の1つがアップグレードされてコードが壊れたため、「git clone;bundle;raketest」シーケンスが合格することを保証しないことを意味します。また、@ chancancodeが言ったように、それは二分するのを非常に難しくします。
また、RailsのgitにはGemfile.lockがあります。
于 2021-08-02T07:54:57.483 に答える
7
Gemfile.lockがないということは、次のことを意味します。
- 新しい貢献者は、奇妙なことが失敗するためにテストを実行できません。そのため、貢献したり、失敗したPRを取得したりすることはありません...悪い最初の経験。
- ローカルのGemfile.lockを紛失した場合、プロジェクトを更新/書き換えずに、古いプロジェクトに戻ってバグを修正することはできません。
->常にGemfile.lockをチェックインし、さらに徹底したい場合はtravisに削除させますhttps://grosser.it/2015/08/14/check-in-your-gemfile-lock/
于 2016-08-15T23:05:55.397 に答える
4
パーティーに少し遅れましたが、答えはまだ私に時間と外国の読書がこの問題を理解するのにかかりました。そこで、Gemfile.lockについて私が見つけたものを要約したいと思います。
Railsアプリを構築するときは、ローカルマシンで特定のバージョンのgemを使用しています。本番モードや他のブランチでのエラーを回避したい場合は、その1つのGemfile.lockファイルをどこでも使用し、bundle変更されるたびにgemを再構築するようにbundlerに指示する必要があります。
Gemfile.lock本番マシンでが変更され、Gitで許可されない場合は、そのファイルの変更を回避するためにgit pull書き込みを行ってから、再度書き込みを行う必要があります。git reset --hardgit pull
于 2013-08-24T04:55:00.247 に答える
0
ここでの他の答えは正しいです：はい、Rubyアプリ（Ruby gemではない）をリポジトリに含める必要がありますGemfile.lock。これを行う必要がある理由を詳しく説明するには、以下をお読みください。
私は、各env（開発、テスト、ステージング、prod ...）がそれぞれbundle install独自のGemfile.lockを構築するという誤った考えにさらされていました。私の仮定は、Gemfile.lockに：test、：prodなどのグループ化データが含まれていないという事実に基づいていました。この仮定は間違っていました。
よく調べてみると、Jenkinsビルドが特定のgem（ffaker、FWIW）のフェッチに成功した理由がわかりませんでしたが、アプリが読み込まれてffakerが必要な場合、ファイルが見つからないと表示されました。WTF？
もう少し調査と実験を行ったところ、2つのファイルの機能がわかりました。
まず、Gemfile.lockを使用して、この特定の環境で使用されないものも含め、すべてのgemをフェッチします。次に、Gemfileを使用して、フェッチされたgemのどれをこの環境で実際に使用するかを選択します。
したがって、Gemfile.lockに基づいて最初のステップでgemをフェッチしたとしても、Gemfileのグループに基づいて、：test環境には含まれていませんでした。
修正（私の場合）はgem 'ffaker'、：developmentグループからメイングループに移動することでした。これにより、すべての環境でそれを使用できるようになりました。（または、必要に応じて、：development、：testにのみ追加します）
于 2020-09-09T18:12:23.910 に答える