Gemfile.lock 应该包含在 .gitignore 中吗？

Question

我对捆绑器及其生成的文件有点陌生。我有一份来自 GitHub 的 git 存储库副本，该存储库由许多人贡献，因此我惊讶地发现捆绑程序创建了一个存储库中不存在且不在 .gitignore 列表。

因为我已经分叉了它，所以我知道将它添加到存储库不会破坏主存储库的任何内容，但如果我执行拉取请求，会导致问题吗？

Gemfile.lock 是否应该包含在存储库中？

Answer 1

当您正在开发需要具有可配置数据库适配器的开源 Rails 应用程序时，真正的问题就会发生。我正在开发 Fat Free CRM 的 Rails 3 分支。
我的偏好是 postgres，但我们希望默认数据库是 mysql2。

在这种情况下，仍然需要使用默认的 gem 集签入 Gemfile.lock，但我需要忽略我在计算机上对其所做的更改。为了实现这一点，我运行：

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]
# -----------------------------------------------------------------------------

我不能说这是否是既定的最佳实践，但它对我来说效果很好。

Answer 2

我和我的同事有不同的Gemfile.lock，因为我们使用不同的平台，windows和mac，而我们的服务器是linux。

我们决定删除repo中的Gemfile.lock并在git repo中创建Gemfile.lock.server，就像database.yml一样。然后在服务器上部署之前，我们使用 cap 部署钩子将 Gemfile.lock.server 复制到服务器上的 Gemfile.lock

Answer 3

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

我认为即使对于插件来说，忽略锁定文件也不是一个好主意。

这意味着“git clone；bundle；rake test”序列不能保证通过，因为您的数十个依赖项之一已升级并使您的代码中断。另外，正如 @chancancode 所说，这使得平分变得更加困难。

Rails 在 git 中也有 Gemfile.lock：

• https://github.com/rails/rails/commit/ 0ad6d27643057f2eccfe8351409a75a6d1bbb9d0

Answer 4

同意 r-dub 的观点，将其保留在源代码控制中，但对我来说，真正的好处是：

在相同的环境中进行协作（忽略 windows 和 linux/mac 的东西）。在 Gemfile.lock 之前，下一个安装该项目的人可能会看到各种令人困惑的错误，并责备自己，但他只是那个幸运的人，获得了超级 gem 的下一个版本，打破了现有的依赖关系。

更糟糕的是，这种情况发生在服务器上，除非受到纪律处分并安装确切的版本，否则会获得未经测试的版本。 Gemfile.lock 使这一点变得明确，并且它会明确告诉您您的版本不同。

注意：记住将内容分组，如：开发和：测试

Answer 5

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 仅列出了三个 gem
（版本严格程度不同），您的应用程序取决于
在几十种宝石上，一旦你考虑到所有的
您所依赖的 gem 的隐式要求。

这很重要：Gemfile.lock 使您的应用程序成为一个单一的
您自己的代码和上次运行的第三方代码的包
到了你确定一切正常的时候了。指定准确的
您在 Gemfile 中依赖的第三方代码的版本将
不提供相同的保证，因为宝石通常声明一个范围
其依赖项的版本。

下次您在同一台计算机上运行捆绑安装时，捆绑程序将
看到它已经拥有您需要的所有依赖项，然后跳过
安装过程。

不要检入 .bundle 目录或其中的任何文件。
这些文件特定于每台特定机器，用于
在捆绑安装运行之间保留安装选项
命令。

如果你运行了bundle pack，gems（虽然不是git gems）
您的捆绑包所需的内容将被下载到供应商/缓存中。捆绑器
如果满足以下条件，则无需连接到互联网（或 RubyGems 服务器）即可运行
您需要的所有宝石都存在于该文件夹中并签入到
你的源代码控制。这是一个可选步骤，不推荐，
由于源代码控制存储库的大小增加。

Answer 6

没有 Gemfile.lock 意味着：

• 新贡献者无法运行测试，因为奇怪的事情会失败，因此他们不会贡献或获得失败的 PR...糟糕的第一次体验。
• 您将无法返回到斧头年前的项目并修复错误，而无需更新/重写项目 ->

如果您丢失了本地 Gemfile.lock ， 始终检查 Gemfile.lock，如果您想更彻底，请让 travis 删除它 https://grosser.it/2015/08/14/check-in-your-gemfile-lock/

Answer 7

来晚了一点，但答案仍然花了我时间和外国阅读来理解这个问题。所以我想总结一下我对 Gemfile.lock 的了解。

当您构建 Rails 应用程序时，您将在本地计算机中使用某些版本的 gem。如果您想避免生产模式和其他分支中的错误，则必须在各处使用该 Gemfile.lock 文件，并告诉捆绑器在每次更改时bundle 重建 gem。

如果 Gemfile.lock 在您的生产机器上发生了更改，并且 Git 不允许您 git pull，您应该将 git reset --hard 写入避免文件更改并再次写入 git pull 。

Answer 8

这里的其他答案是正确的：是的，您的 Ruby 应用程序（不是您的 Ruby gem）应该在存储库中包含 Gemfile.lock 。要详细了解为什么应该这样做，请继续阅读：

我错误地认为每个环境（开发、测试、登台、产品...）都执行了捆绑安装 构建自己的 Gemfile.lock。我的假设是基于 Gemfile.lock 不包含任何分组数据的事实，例如 :test、:prod 等。这个假设是错误的，正如我在一个痛苦的本地问题中发现的那样。

经过仔细调查，我很困惑为什么我的 Jenkins 构建显示成功获取特定的 gem（ffaker，FWIW），但是当应用程序加载并需要 ffaker 时，它说找不到文件。搞什么？

更多的调查和实验显示了这两个文件的作用：

首先，它使用 Gemfile.lock 来获取所有 gem，甚至是那些不会在该特定环境中使用的 gem。 然后它使用 Gemfile 来选择在这个环境中实际使用那些获取的 gem。

因此，尽管它在第一步中基于 Gemfile.lock 获取了 gem，但它并未包含在我的 :test 环境中（基于 Gemfile 中的组）。

修复（在我的例子中）是将 gem 'ffaker' 从 :development 组移动到主组，这样所有的环境都可以使用它。 （或者，根据情况仅将其添加到 :development、:test 中）

Answer 9

2022 年更新，来自 TrinitronX

快进到 2021 年，现在Bundler 文档< /a> [web archive] 现在说将 Gemfile.lock 提交到 gem 中... ́_(ツ)_/́ 我想这对于开发人员来说很有意义，并且在开始项目时易于使用。但是，现在 CI 作业需要确保删除任何杂散的 Gemfile.lock 文件以针对其他版本进行测试。

遗留答案 ~2010

假设您没有编写 ruby​​gem，Gemfile.lock 应该位于您的存储库中。它用作所有所需 gem 及其依赖项的快照。这样，bundler 就不必在每次部署等时重新计算所有 gem 依赖项。

来自下面的牛仔编码的评论：

如果您正在处理 gem，请不要签入您的 Gemfile.lock。如果您正在开发 Rails 应用程序，请检查您的 Gemfile.lock。

这是一篇不错的文章解释锁定文件是什么。