Gemfile.lock应该包含在.gitignore中吗?
我对捆绑器和它生成的文件有点新鲜。 我有一个GitHub的git回购副本,很多人都在贡献,所以我很惊讶地发现,bundler创build了一个不存在于回购中但不在.gitignore
列表中的文件。
由于我已经分叉了,我知道把它添加到回购将不会破坏任何主要回购,但如果我做一个拉请求,会导致一个问题?
Gemfile.lock
应该包含在存储库中吗?
假设你不写一个rubygem,Gemfile.lock应该在你的仓库中。 它被用作所有你需要的gem及其依赖的快照。 这样bundler不必在每次部署时重新计算所有的gem依赖关系,等等。
来自cowboycoded的评论。
如果你正在做一个gem,那么不要检查你的Gemfile.lock。
这里有一个很好的文章解释什么是locking文件。
真正的问题发生在你正在开发一个需要一个可configuration数据库适配器的开源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。
我们决定在repo中删除Gemfile.lock,并在git repo中创buildGemfile.lock.server,就像database.yml一样。 然后,在将其部署到服务器之前,我们使用cap deploy hook将Gemfile.lock.server复制到服务器上的Gemfile.lock
同意r-dub,保持在源代码控制,但对我来说,真正的好处是这样的:
在相同的环境下进行协作 (无视windohs和linux / mac的东西)。 在Gemfile.lock之前,下一位安装该项目的家伙可能会看到各种各样令人困惑的错误,并指责自己,但他只是那个幸运的人获得了下一个超级gem版本,打破了现有的依赖关系。
更糟糕的是,这发生在服务器上,除非受到严格的规定和安装确切的版本,否则会得到未经testing的版本。 gemfile.lock明确地表明了这一点,它会明确告诉你,你的版本是不同的。
注意:记住把东西分组,如:开发和testing
Bundler文档也解决了这个问题:
原文: http : //gembundler.com/v1.3/rationale.html
编辑: http ://web.archive.org/web/20160309170442/http: //bundler.io/v1.3/rationale.html
请参阅“将您的代码检入版本控制”一节:
在开发你的应用程序一段时间后,检查应用程序连同Gemfile和Gemfile.lock快照。 现在,您的存储库logging了您最后一次确定应用程序工作的所有gem的确切版本。 请记住,当您的Gemfile仅列出三个gem(具有不同程度的版本严格性)时,您的应用程序依赖于几十个gem,一旦考虑了所依赖的所有gem的隐含需求。
这一点很重要:Gemfile.lock使您的应用程序成为您自己的代码和上次运行的第三方代码的一个包,确保一切正常。 在您的Gemfile中指定您所依赖的第三方代码的确切版本将不会提供相同的保证,因为gems通常会为其依赖项声明一系列版本。
下一次在同一台机器上运行bundle install时,bundler会看到它已经拥有了你需要的所有依赖,并跳过安装过程。
不要检入.bundle目录或其中的任何文件。 这些文件是特定于每台特定的计算机的,用于在bundle install命令的运行之间持久化安装选项。
如果你已经运行了捆绑软件包,你的捆绑软件所需要的gem(尽pipe不是gitgem)将被下载到供应商/caching中。 Bundler可以在没有连接到互联网(或RubyGems服务器)的情况下运行,如果您需要的所有gem都存在于该文件夹中并签入到您的源代码pipe理中。 这是一个可选的步骤,由于源代码控制库的大小增加,不build议这样做。
晚会有点晚了,但答案还是花了我时间和外国读书来了解这个问题。 所以我想总结一下我对Gemfile.lock的了解。
在构buildRails应用程序时,您在本地机器上使用某些版本的gem。 如果你想避免在生产模式和其他分支的错误,你必须在任何地方使用一个Gemfile.lock文件,并告诉捆绑器bundle
重buildgem,每当它发生变化。
如果你的生产机器上的Gemfile.lock
已经改变了,Git不会让你的git pull
,你应该写git reset --hard
来避免这个文件的改变,然后再写git pull
。
没有Gemfile.lock的意思是:
- 新的贡献者不能运行testing,因为奇怪的事情失败了,所以他们将不会贡献或得到失败的PR …糟糕的第一次经历。
- 如果你丢失了本地的Gemfile.lock,你将无法重新开始修复项目,修复bug,而不必更新/重写项目
– >总是检查Gemfile.lock,让travis删除它,如果你想要更彻底https://grosser.it/2015/08/14/check-in-your-gemfile-lock/