为什么要在版本控制下包含 Podfile.lock？答案

【问题标题】：Why should you include Podfile.lock under version control?为什么要在版本控制下包含 Podfile.lock？
【发布时间】：2017-10-17 02:43:43
【问题描述】：

首先，我想提一下，我已经阅读了 cocoapods 指南https://guides.cocoapods.org/using/pod-install-vs-update.html

在一个每个人都只使用 pod install 命令并且我们在播客文件。 .lock 文件似乎是多余的。

假设我们有一个使用 ReactiveSwift 的项目。 ReactiveSwift 在其 podspec 中对 Result pod 的依赖如下：

  s.dependency 'Result', '~> 3.2'

我的假设是我不应该真正关心 ReactiveSwift 依赖什么，因为我只是要对我严格指定的 ReactiveSwift 版本进行 pod 安装。

对于我自己开发的 pod，我可以影响他们的 podfile 和 podspec 来严格指定我想使用的一个版本。

所以我的项目中没有 podfile.lock 的简化流程将是：

开发一个功能，如果它需要更改依赖版本 - 只需直接在 podfile 中指定它，而无需提交 Podfile.lock
将功能合并到 master 分支，然后 CI 使用新的 podfile 运行 pod install 命令
现在 CI 拥有其使用的所有正确版本的 pod，并且可以正确构建我的应用程序

在那种情况下是否需要 Podfile.lock ？

【问题讨论】：

当有人更新 Podfile 而你不知道时，这是一种保护措施。在构建时，Podfile.lock 将根据 Manifest.lock 进行验证 - 如果它们相同，则构建继续。如果没有，您会收到错误消息，告诉您需要更新机器上的 pod。 CI 服务器每次运行pod install 当然是有意义的，但在每次代码签出时记住它是没有意义的。
@Losiowaty 添加答案？
您的 pod 的依赖关系可能会引入重大更改。您不希望这种情况随机发生。大多数依赖管理器中都引入了相同的东西，例如javascript 的 npm。

标签： ios cocoapods

【解决方案1】：

首先，我想引用the official doc：

什么是Podfile.lock

此文件在pod install 首次运行后生成，用于跟踪已安装的每个 Pod 的版本。例如，想象一下 Podfile 中指定的以下依赖项：

pod 'RestKit'

运行pod install 将安装当前版本的RestKit，导致生成一个Podfile.lock，指示安装的确切版本（例如RestKit 0.10.3）。感谢Podfile.lock，即使有更新的版本可用，稍后在另一台机器上运行这个假设项目的pod install 仍将安装RestKit 0.10.3。 CocoaPods 将遵循 Podfile.lock 中的 Pod 版本，除非在 Podfile 中更新了依赖项或调用了 pod update（这将导致生成新的 Podfile.lock）。

回到你的问题：

如上所述，如果您的设置中每个人都只使用pod install 命令，并且每个依赖版本都在 podfile 和相关 podspec 中严格指定，那么Podfile.lock 似乎是多余的。

但是，我认为这种情况很少见，而不是Cocoapods 的常见用法。

例如，我们可以

忽略指定版本以始终使用最新版本的 pod，例如 pod 'RestKit'
使用运算符~> 0.1.2指定版本0.1.2和0.2以下的版本，不包括0.2
添加第 3 方 pod，这些 podspec 不受控制
等

在这种情况下，提交Podfile.lock 将非常有用。

顺便说一句，我认为问题标题最好改成

Why should you include Podfile.lock under version control?

到

Why should I include Podfile.lock under version control in this scenario?

【讨论】：

【解决方案2】：

问题是你必须关心依赖关系的变化。

虽然语义版本控制应该确保没有在次要版本或补丁版本中引入重大更改，但它仍然可能发生（一些常用的 pod 仍在版本 0.x！）

当这种情况发生并且依赖项引入了重大更改时，您的应用程序可能会开始崩溃甚至无法构建。除非您有良好的自动测试，否则您不会知道它。

或者，新的开发人员克隆了您的存储库，但由于依赖项的更改而无法编译。

或者反过来。您的客户报告了某个版本的错误，您无法在当前版本上重现它。因此，您返回到构建版本的先前提交。而且你也无法重现它，因为在依赖补丁中修复了一个错误。

实际上，完全有可能当您返回之前的提交并重新安装 pod 时，您的项目甚至无法编译（如果您不锁定依赖项，这在 javascript 世界中很常见）。

总之，锁定依赖是一种实现确定性构建的方法，它不依赖于外部更改。对于 cocoapods，将已安装的 pod 提交到您的存储库也很常见（讨论这是一个好主意还是坏主意是另一回事，两者都有很好的论据）。

【讨论】：

【解决方案3】：

您的Podfile 指定了您的直接依赖项的版本，但它可能会产生一些歧义。例如，也许您需要 2.2 版的库，但您并不关心您获得的是 2.2.1 还是 2.2.2。第一次执行pod install 时，Cocoapods 将获得最新版本的 2.2.x。

但是，也许 2.2.2 有一个错误，您在不知不觉中依赖于您的应用程序。维护者发布了 2.2.3，如果您还没有检查您的同事之一的锁定文件，或者您的 CI 系统构建了应用程序的崩溃版本并导致各种混乱。（它仍然可以在您的机器上运行！）

除了锁定直接依赖项的确切版本之外，锁定传递依赖项同样重要。

总之，Podfile.lock 确保您不会意外升级您引入的库，同时让您的 Podfile 只关心您的直接依赖项。

【讨论】：