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

Should Gemfile.lock be included in .gitignore?

提问by aarona

I'm sort of new to bundler and the files it generates. I have a copy of a git repo from GitHub that is being contributed to by many people so I was surprised to find that bundler created a file that didn't exist in the repo and wasn't in the .gitignorelist.

我对 bundler 及其生成的文件有点陌生。我有一份来自 GitHub 的 git repo 副本，该副本由许多人提供，因此我惊讶地发现 bundler 创建了一个在 repo 中不存在且不在.gitignore列表中的文件。

Since I have forked it, I know adding it to the repo won't break anything for the main repo, but if I do a pull request, will it cause a problem?

由于我已经分叉了它，我知道将它添加到 repo 不会破坏主 repo 的任何内容，但是如果我执行拉取请求，会导致问题吗？

Should Gemfile.lockbe included in the repository?

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

回答by rwilliams

Assuming you're not writing a rubygem, Gemfile.lock should be in your repository. It's used as a snapshot of all your required gems and their dependencies. This way bundler doesn't have to recalculate all the gem dependencies each time you deploy, etc.

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

From cowboycoded's comment below:

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

If you are working on a gem, then DO NOT check in your Gemfile.lock. If you are working on a Rails app, then DO check in your Gemfile.lock.

如果你正在处理一个 gem，那么不要检查你的 Gemfile.lock。如果您正在开发 Rails 应用程序，请务必检查您的 Gemfile.lock。

Here's a nice articleexplaining what the lock file is.

这是一篇很好的文章，解释了锁定文件是什么。

回答by ndbroadbent

The real problem happens when you are working on an open-source Rails app that needs to have a configurable database adapter. I'm developing the Rails 3 branch of Fat Free CRM. My preference is postgres, but we want the default database to be mysql2.

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

In this case, Gemfile.lockstill needs be checked in with the default set of gems, but I need to ignore changes that I have made to it on my machine. To accomplish this, I run:

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

git update-index --assume-unchanged Gemfile.lock

and to reverse:

并扭转：

git update-index --no-assume-unchanged Gemfile.lock

It is also useful to include something like the following code in your Gemfile. This loads the appropriate database adapter gem, based on your database.yml.

在您的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]
# -----------------------------------------------------------------------------

I can't say if this is an established best practice or not, but it works well for me.

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

回答by Joe Yang

My workmates and I have different Gemfile.lock, because we use different platforms, windows and mac, and our server is linux.

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

We decide to remove Gemfile.lock in repo and create Gemfile.lock.server in git repo, just like database.yml. Then before deploy it on server, we copy Gemfile.lock.server to Gemfile.lock on server using cap deploy hook

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

回答by Joe Yang

The Bundler docs address this question as well:

Bundler 文档也解决了这个问题：

ORIGINAL: http://gembundler.com/v1.3/rationale.html

原文：http: //gembundler.com/v1.3/rationale.html

EDIT: http://web.archive.org/web/20160309170442/http://bundler.io/v1.3/rationale.html

编辑：http://web.archive.org/web/20160309170442/http: //bundler.io/v1.3/rationale.html

See the section called "Checking Your Code into Version Control":

请参阅名为“将代码检查到版本控制中”的部分：

After developing your application for a while, check in the application together with the Gemfile and Gemfile.lock snapshot. Now, your repository has a record of the exact versions of all of the gems that you used the last time you know for sure that the application worked. Keep in mind that while your Gemfile lists only three gems (with varying degrees of version strictness), your application depends on dozens of gems, once you take into consideration all of the implicit requirements of the gems you depend on.

This is important: the Gemfile.lock makes your application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked. Specifying exact versions of the third-party code you depend on in your Gemfile would not provide the same guarantee, because gems usually declare a range of versions for their dependencies.

The next time you run bundle install on the same machine, bundler will see that it already has all of the dependencies you need, and skip the installation process.

Do not check in the .bundle directory, or any of the files inside it. Those files are specific to each particular machine, and are used to persist installation options between runs of the bundle install command.

If you have run bundle pack, the gems (although not the git gems) required by your bundle will be downloaded into vendor/cache. Bundler can run without connecting to the internet (or the RubyGems server) if all the gems you need are present in that folder and checked in to your source control. This is an optional step, and not recommended, due to the increase in size of your source control repository.

在开发应用程序一段时间后，将应用程序与 Gemfile 和 Gemfile.lock 快照一起检入。现在，您的存储库记录了您上次确定应用程序运行时使用的所有 gem 的确切版本。请记住，虽然您的 Gemfile 仅列出了三个 gem（具有不同程度的版本严格性），但您的应用程序依赖于数十个 gem，一旦您考虑了所依赖的 gem 的所有隐式要求。

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

下次您在同一台机器上运行 bundle install 时，bundler 会看到它已经拥有您需要的所有依赖项，并跳过安装过程。

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

如果您运行了 bundle pack，您的 bundle 所需的 gems（虽然不是 git gems）将被下载到 vendor/cache 中。如果您需要的所有 gem 都存在于该文件夹中并已签入源代码管理，则 Bundler 无需连接到 Internet（或 RubyGems 服务器）即可运行。由于源控制存储库的大小增加，因此这是一个可选步骤，不推荐使用。

回答by oma

Agreeing with r-dub, keep it in source control, but to me, the real benefit is this:

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

collaboration in identical environments(disregarding the windohs and linux/mac stuff). Before Gemfile.lock, the next dude to install the project might see all kinds of confusing errors, blaming himself, but he was just that lucky guy getting the next version of super gem, breaking existing dependencies.

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

Worse, this happened on the servers, getting untested version unless being disciplined and install exact version. Gemfile.lock makes this explicit, and it will explicitly tell you that your versions are different.

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

Note: remember to group stuff, as :development and :test

注意：记住将东西分组，如 :development 和 :test

回答by grosser

No Gemfile.lock means:

没有 Gemfile.lock 意味着：

• new contributors cannot run tests because weird things fail, so they won't contribute or get failing PRs ... bad first experience.
• you cannot go back to a x year old project and fix a bug without having to update/rewrite the project if you lost your local Gemfile.lock

• 新的贡献者不能运行测试，因为奇怪的事情失败了，所以他们不会贡献或得到失败的 PR ......糟糕的第一次体验。
• 如果您丢失了本地 Gemfile.lock，您将无法回到 ax 年的项目并修复错误而不必更新/重写项目

-> Always check in Gemfile.lock, make travis delete it if you want to be extra thorough https://grosser.it/2015/08/14/check-in-your-gemfile-lock/

-> 总是检查 Gemfile.lock，如果你想更彻底，让 travis 删除它https://grosser.it/2015/08/14/check-in-your-gemfile-lock/

回答by Gediminas

A little late to the party, but answers still took me time and foreign reads to understand this problem. So I want to summarize what I have find out about the Gemfile.lock.

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

When you are building a Rails App, you are using certain versions of gems in your local machine. If you want to avoid errors in the production mode and other branches, you have to use that one Gemfile.lock file everywhere and tell bundler to bundlefor rebuilding gems every time it changes.

当您构建 Rails 应用程序时，您在本地机器上使用某些版本的 gem。如果你想避免生产模式和其他分支中的错误，你必须在任何地方使用那个 Gemfile.lock 文件，并告诉 bundlerbundle每次更改时重建 gems。

If Gemfile.lockhas changed on your production machine and Git doesn't let you git pull, you should write git reset --hardto avoid that file change and write git pullagain.

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