如何在协作上下文中处理捆绑器更新（Gemfile.lock）？

Posted 2023-02-15

【中文标题】如何在协作上下文中处理捆绑器更新（Gemfile.lock）？

【英文标题】：How to deal with bundler updates (Gemfile.lock) in collaborative context?

【发布时间】：2013-01-06 10:11:04

【问题描述】：

我一直是一个特定项目的孤独程序员，但现在其他人作为合作者加入了。图片中只有我一个人，bundler 的更新一直很顺利，我从未想过Gemfile.lock 会被 Git 跟踪。

新的合作者在克隆 repo 后运行bundle install，Gemfile.lock 更新如下：

Gemfile.lock

@@ -141,7 +141,7 @@ GEM
       rack-ssl (~> 1.3.2)
       rake (>= 0.8.7)
       rdoc (~> 3.4)
-      thor (< 2.0, >= 0.14.6)
+      thor (>= 0.14.6, < 2.0)
     raindrops (0.10.0)
     rake (0.9.2.2)
     rdoc (3.12)
@@ -164,7 +164,7 @@ GEM
     sprockets (2.1.3)
       hike (~> 1.2)
       rack (~> 1.0)
-      tilt (!= 1.3.0, ~> 1.1)
+      tilt (~> 1.1, != 1.3.0)
     thor (0.16.0)
     tilt (1.3.3)
     treetop (1.4.10)
@@ -175,7 +175,7 @@ GEM
     tzinfo (0.3.33)
     uglifier (1.3.0)
       execjs (>= 0.3.0)
-      multi_json (>= 1.0.2, ~> 1.0)
+      multi_json (~> 1.0, >= 1.0.2)
     unicorn (4.3.1)
       kgio (~> 2.6)
       rack

此更改已推送到 master 的命名分支中。我应该如何应对这种变化？

大声思考：我是否要在 GitHub 上合并拉取请求？我是否一开始就从上游拉取而没有拉取请求？我是否运行特定的捆绑程序命令来与其他协作者的Gemfile.lock 同步？有没有其他合作者可以做不同的事情，这样他们就不会导致任何 gem 更新（相反，只是下载现有 Gemfile.lock 中指定的 gem）？针对这种情况的最佳做法是什么？

【参考方案1】：

Gemfile.lock 应该受版本控制。您应该对其进行任何更改。当有人（您信任的人）更新它时，您应该运行bundle install 来安装当前锁定在 Gemfile.lock 中的 gem。

仅运行bundle install 不会更新现有的 Gemfile.lock。为此，您需要运行bundle update。

话虽如此，您的 Gemfile.lock 中的版本并没有实际变化。改变的只是几行参数的顺序。您可以安全地将这些更改合并或忽略它们；生成的 Gemfile.lock 将（功能上）相同。

【讨论】：

将 Gemfile.lock 置于版本控制之下被认为是最佳实践。这样可以确保无论您在何处安装应用程序，无论是其他开发人员在处理源代码，还是为您的生产服务器安装该包，都将构建相同的依赖包。

确保你们都使用相同的捆绑器版本，以便生成的 Gemfile.lock 看起来相同，并且不会生成不同的东西，这将是一个误报提交