介绍
许多使用 CocoaPods 的开发人员似乎认为 pod install 紧在第一次使用 CocoaPods 设置项目的时候使用,并且之后都是使用 pod update. 但是事实并非如此.
本指南的目的是解释何时应使用 pod install 以及何时应使 用 pod update 更新。
- 在你的项目中使用
pod install来添加新的 pod,即使在这之前你已经有了Podfile 并且运行过pod install;所以,在你只是想在项目中添加或者删除 pod 的时候使用pod install. - 当你想把 pod 更新至新的版本的时候使用
pod update [PODNAME];
命令的详细介绍
注: install 和 update 这两个命令并不是 CocoaPods 所特定的命令. 它受到了许多其他一来管理器的启发,比如 : bundler, RubyGems or composer, 他们都有类似的命令, 其行为和意图与本文档中描述的一致.
pod install
这是在您第一次检索项目的 pods 时使用的，也是每次编辑Podfile以添加，更新或删除 pod 的时候使用的。
每次运行pod install命令并下载并安装新的pod时，都会在Podfile.lock文件中为每个pod写入已安装的版本。 该文件会跟踪每个 pod 的安装版本并锁定这些版本。
-
运行
pod install时，它仅解决 Podfile.lock 中未列出的 pod 的依赖关系。- 对于 Podfile.lock 中列出的 Pod ，它将下载 Podfile.lock 中列出的显式版本，而不尝试检查是否有更新的版本可用
- 对于没有在 Podfile.lock 中列出的 pod ，它会搜索与 Podfile 中描述的内容相匹配的版本（例如，在“Pod”中，如'Pod'，'〜> 1.2'）
pod outdated
当您运行 pod outdated 时，CocoaPods 将列出所有具有比 Podfile.lock 中列出的更新版本的 pod（当前为每个 pod 安装的版本）。 这意味着如果您在这些窗格上运行 pod update PODNAME，只要新版本与您的 Podfile中设置的pod 'MyPod'，'〜> x.y' 等限制匹配，就会更新它们。
pod update
当您运行 pod update PODNAME 时，CocoaPods 将尝试查找 pod PODNAME 的更新版本，而不考虑 Podfile.lock 中列出的版本。 它会将 pod 更新为最新版本（只要它符合 Podfile 中的版本限制）。
如果你不带 pod name 运行 pod update, CocoaPods 会将 Podfile 中的每个 pod 更新为最新版本.
预期用法
使用 Pod update PODNAME，您将只能更新特定的 Pod（检查是否存在新版本并相应地更新 Pod ）。 与 pod install 相反，pod install 不会尝试更新已安装的 pod 版本。
在 Podfile 中添加了新的 pod 时, 应该使用 pod install 命令, 而不是pod update 去暗转新的 pod. 这样做可以避免在同一过程中去更新或者安装那些已经存在的 pod.
只有在想更新特定的 pod 时使用 pod update PODNAME 命令
提交你的 Podfile.lock 文件(Commit your Podfile.lock)
提醒一下，即使您的策略不是将 Pods 文件夹提交到共享存储库，也应该始终提交(commit)并推送 (push) 您的Podfile.lock文件。
否则，它会打破上面解释的关于 pod install 能够锁定已安装版本的 pod 的整个逻辑。
场景示例
阶段1：user1创建项目
user1创建一个项目并希望使用 pod A，B，C。 他们使用这些 pod 创建Podfile，然后运行pod install。
这将安装 pod A，B，C，它们都在1.0.0版本中。
Podfile.lock会记录下来，注意A，B和C每个都安装为版本1.0.0。
顺便说一下，因为这是他们第一次运行 pod 安装，并且 Pods.xcodeproj 项目尚不存在，该命令还会创建Pods.xcodeproj 和 .xcworkspace，但这是该命令的副作用，而不是其主要角色。
阶段2：user1添加一个新的pod
稍后，user1想要将Pod D添加到其Podfile中。
因此，他们应该在讲 pod D 添加到 Podfile 中后运行 pod install，以便即使 pod B 的主要人员在第一次执行pod install后发布了 pod B 的1.1.0版本，该项目仍会继续使用1.0.0版本 - 因为user1只需要添加 pod D，而不会冒着对 pod B 的意外更新的风险。
这就是有些人错误的地方，因为他们在这里使用 pod update - 可能会认为这是“我想用新的 pod 更新我的项目”？ - 而不是使用 pod isntall - 在项目中安装新的 pod。
阶段3：user2加入该项目
然后，从未参与过该项目的 user2 加入该团队。 他们 clone 存储库，然后使用 pos install。
Podfile.lock 的内容（应该被提交到git仓库中）将保证它们将得到完全相同的 pod，并且使用与 user1 完全相同的版本。
即使 pod C 的版本1.2.0现在可以使用，user2 也将获得版本1.0.0中的版本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），但会保留版本 1.0.0 中的pod C（并且不会将其更新为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版本中获得A2版本（因为那时是A2的最新版本）
- 而当 user2 稍后加入项目时运行 pod install 时，他们可能会在版本3.5中获得 pod A2（因为A2的维护者可能在此期间发布了新版本）。
这就是为什么确保每个团队成员使用每台计算机上所有 pod 的相同版本的唯一方法;
使用Podfile.lock并正确使用 pod install 与pod update。
