iOS之Pod install VS Pod update

此文为翻译文章，原文网址：https://guides.cocoapods.org/using/pod-install-vs-update.html

前言：

很多初次接触CocoaPods的人一般都会认为pod install仅仅被使用在项目刚创建时，pod update是在创建项目之后使用，但事实并非如此。

这篇文章的目的是为了告诉你pod install和pod update分别该在什么时候使用

TL;TD：

在项目中使用pod install安装新的pods，即使项目中以前已经运行过pod install，当adding/removing pods时也用pod install

当你需要更新pods到一个新版本时用pod update[PODNAME]

pod install:

这将在您首次检索项目的pod时使用，也可以在您每次编辑您的Podfile为了添加、删除、更新一个pod时使用。每一次pod install命令运行时，将会下载和安装新的pods，同时会将每个pod安装的版本写入Podfile.lock（该文件跟踪每个pod的已安装版本，并锁定这些版本）文件中.

运行pod安装时，它仅解析Podfile.lock中尚未列出的pod的依赖关系。对于Podfile.lock中列出的pod，它会下载Podfile.lock中列出的显式版本，而不尝试检查较新的版本是否可用，对于Podfile.lock中未列出的pod，它会搜索与Podfile中描述的版本相匹配的版本（如pod中的“MyPod”，“～> 1.2”）

pod outdated:

当你运行pod outdated时，CocoaPods将会列出有新版本存在的所有pods，这意味着如果你运行pod update，列出的这些pods将会被更新

pod update

当你运行pod update[PODNAME]时，CocoaPod将尝试找到更新版本的PODNAME，而不考虑Podfile.lock中列出的版本。它会将pod更新到最新版本（只要它符合Podfile中的版本限制）

如果您运行pod update时，CocoaPods会将您的Podfile中列出的每个pod更新为可能的最新版本。

提交Podfile.lock:

作为提醒，即使您的策略不是将Pods文件夹提交到共享存储库中，您应该始终提交并推送您的Podfile.lock文件。

否则，将破坏上述关于pod安装能够锁定您的pod的已安装版本的整个逻辑。

场景示例:

这是一个场景示例来说明在项目生命周期中可能遇到的各种用例。

阶段1：User1创建项目

user1创建一个项目，并想使用pod A，B，C。他们用这些pod创建一个Podfile，并运行pod安装。这将安装pod A，B，C，我们将说的是1.0.0版本。Podfile.lock将跟踪它，并注意到A，B和C都安装为1.0.0版本。顺便说一下，因为这是第一次运行pod install，而且Pods.xcodeproj项目还不存在，所以命令也将创建Pods.xcodeproj和.xcworkspace，但这是命令的副作用，而不是它的主要角色。

阶段2：User1添加一个新的pod

后来，user1想要将pod D添加到它们的Podfile中。

他应该使用pod install，所以即使pod B的发布者从第一次执行pod安装后发布了一个1.1.0版本的pod，但该项目仍将继续使用版本1.0.0 -因为user1只想添加pod D，而不会意外更新pod B.

这儿很多人会犯错误地使用pod更新-他们可能认为这是“我想用新的pod更新我的项目”？-而不是使用pod install -在项目中安装新的pod。

阶段3：User2加入项目

以前从未参与过该项目的user2加入了团队。它们克隆存储库，然后使用pod安装。

Podfile.lock（应该提交到git repo上）的内容将保证它们将获得与user1正在使用的完全相同的pod。

即使现在可以使用版本1.2.0的pod C，user2将会在版本1.0.0中获得pod C。因为这是在Podfile.lock中注册的。pod C被Podfile.lock锁定到版本1.0.0（因此这个文件的名称）。

阶段4：检查pod的新版本

之后，user1想要检查是否有可用于pod的更新。他们运行pod outdated告诉他们pod B有一个新的1.1.0版本，pod C有一个新的1.2.0版本发布。

user1决定他们想要更新pod B，而不是pod C;所以他们将运行pod update B，它将B版本从1.0.0版升级到1.1.0版本（并相应地更新Podfile.lock），但会将pod C保留在1.0.0版本中（不会将其更新为1.2. 0）。

在Podfile中使用确切的版本是不够的:

有些人可能会认为，通过在其Podfile中指定其pod的确切版本，如pod'A'，'1.0.0'，足以保证每个用户与团队中的其他人具有相同的版本。

然后当他们使用pod update时甚至仅仅添加一个新的pod时，认为不会有更新其他pod的风险，仅仅是因为它们固定到Podfile中的特定版本。

但事实上，这还不足以保证我们上述情况中的user1和user2将始终得到完全相同版本的所有pod。

一个典型的例子是如果pod A具有对pod A2的依赖 ， 在A.podspec中声明为依赖关系“A2”，“～> 3.0”。在这种情况下，在您的Podfile中使用pod'A'，'1.0.0'将确实强制user1和user2始终使用pod A的1.0.0版本，但是：

user1可能会在版本3.4中结束pod A2（因为那时是A2的最新版本）

而当user2在以后加入项目时运行pod安装时，他们可能会在版本3.5中获得pod A2（因为A2的维护者可能在此期间发布了新版本）。

这就是为什么唯一的方法是确保每个团队成员在每个计算机上使用相同版本的所有pod的方法是使用Podfile.lock并正确使用pod install vs pod update