介绍
许多人在刚开始使用 CocoaPods 时，似乎认为只有在第一次使用 CocoaPods 设置项目时才会使用 pod install，而在之后都使用 pod update。但事实并非如此。
这篇文章的目的是解释什么时候使用 pod install，什么时候使用 pod update。
- 只要向使用 CocoaPods 的工程中添加或移除库，就需要使用pod install。即使之前已经有 Podfile 文件并运行过 pod install。
- 只有在需要将库更新到新的版本时，使用 pod update [PODNAME]。
命令的详细说明
注意：install和update的词汇表实际上并不特定于CocoaPods。它的灵感来自许多其他依赖关系管理器，
如bundler、RubyGems或composer，它们具有类似的命令，其行为和意图与本文中描述的完全相同。
pod install
这将在你第一次要为项目检索 pod 库时使用，但也会在每次编辑 Podfile 文件来添加、更新或删除 pod 时使用。
- 每次运行 pod install 命令（下载并安装新的 pod 库）时，都会将已安装的 pod 文件的版本号写入 Podfile.lock 文件中。这个文件记录每个 pod 库的安装版本并锁定这些版本。
- 当你使用 pod install 时，它只解析没有在 Podfile.lock 文件中列出的库的依赖关系。
- 对于在 Podfile.lock 中列出的库文件，它只会下载在 Podfile.lock 中明确指定的版本号，不会去检查是否有更新的版本。
- 对于还没有在 Podfile.lock 中列出的库文件，它会检索与 Podfile 文件中描述相匹配的版本（如：pod 'MyPod', '~>1.2'）。
pod outdated
当运行 pod outdated 命令时，CocoaPods 会列出那些所有比 Podfile.lock 里面有新版本的库（那些当前被安装着的库的版本）。这个意思就是，如果你对这些库执行 pod update PODNAME 命令，并且新版本仍符合在 Podfile 里的限制（如：pod 'MyPod', '~>x.y'），它就会被更新。
pod update
当运行 pod update PODNAME 命令时，CocoaPods 会尝试将指定的库更新到最新版本，不会受 Podfile.lock 文件中列出的版本号限制。它会将这个库尽可能地更新到最新版本（只要期符合 Podfile 中的版本号限制即可）。
如果运行 pod update 命令没有指定库的名称，CocoaPods 会将 Podfile 中列出的所有库都尽可能的更新到最新版本。
预期用法
使用 pod update PODNAME 命令，可以更新指定库的版本号（检查是否存在新版本，相应的进行更新）。相反地，pod install 不会将已存在的库更新到最新版本。
当向 Podfile 中添加新库时，应该使用 pod install，而不是 pod update，只安装这个新库而消除了在同一个进程中更新已存在库的风险。
提交 Podfile.lock 文件
作为提醒，即使你的原则是不提交 pod 文件到远程仓库中，但是你应该将 Podfile.lock 文件提交和 push 到远程。
否则，它将破坏上面解释的 pod install 能够锁定 pod 库的已安装版本的整个逻辑。
例子
下面是一个场景示例来说明在项目生命周期中可能遇到的各种用例。
场景1：User1 创建了一个工程
user1 创建了一个工程，并且想要使用 A、B、C 三个库。他们创建了一个包含这三个库的 podfile 文件，并运行 pod install。
这将安装 A、B、C 这三个库，我们认为它们都是 1.0.0 版本。
Podfile.lock 文件将对此进行跟踪，并标注 A、B 和 C 分别作为1.0.0版安装。
顺便说一句，因为是第一次运行 pod install，Pods.xcodeproj 工程还不存在，所以这个命令还会创建
Pods.xcodeproj 和 .xcworkspace，这只是这个命令的副作用，并不是主要的。
场景2：User1 添加一个新库
随后，user1 想要在 podfile 文件中添加一个新库 D。
之后，他们就应该运行 pod install 命令了，这时，即使在第一次执行 pod install 之后， pod B 的维护者发布了 1.1.0 版本，工程中仍会使用 1.0.0 版本，因为 user1 只想添加一个新库 D，没有 Pod B 被意外更新的危险。
这就是有些人弄错的地方，因为他们在这里使用 pod update 来代替 pod install，可能认为这是“我想用新的
pod 更新我的项目”，而不是在项目中添加一个新的 pod。
场景3：User2 加入到这个项目
然后 user2 加入了团队，他们以前从未参与过这个项目。他们 clone 了一份仓库，然后使用 pod install 命令。
Podfile.lock 中的内容会保障他们得到完全相同的 pod 库，与 user1 使用的版本完全相同。
即使 pod C 的可用版本号已经是 1.2.0 了，user2 会获取 1.0.0 版本的 pod C。因为那就是在 Podfile.lock 文件中注册的版本号。pod C 的版本号被 Podfile.lock 锁定为 1.0.0（）
场景4：检查 pod 是否有新版本
随后，用户想要检查 pods 库是否有可用的更新，他们运行 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 文件也会更新），但是 C 的版本号保持不变，仍是 1.0.0 版本（不会更新到 1.2.0版本）。
在 Podfile 中使用精确的版本是不够的
有些人可能认为，通过在 podfile 文件中指定 pod 的确切版本，比如：pod'A'、'1.0.0'，就足以保证每个人都拥有与团队中其他人相同的版本。
然后，他们甚至还使用 pod update，即使只是添加了一个新库，认为更新其它 pod 不会有什么风险，因为其它的库在 podfile 中已经被限制了指定的版本号。
但事实上，这还不足以保证上述场景中的 user1 和 user2 总是获得完全相同的 pod 版本。
一个典型的例子是如果 pod A 对 pod A2 有依赖关系，在 A.podspec 中声明为依赖关系'A2'，'~>3.0'。在这种情况下，在 pod 文件中使用 pod'A'、'1.0.0' 确实会强制 user1 和 user2 始终使用 pod A 的 1.0.0 版本，但是：
- user1 可能会使用依赖库 A2 的 3.4版本（因为那是当时A2的最新版本）。
- 当 user2 在加入项目后，运行 pod install 时，他们可能会得到依赖库 A2 的 3.5 版本（因为A2的维护者可能在此期间发布了一个新版本）。
所以只有一个方法来保证项目中的每个开发者都使用相同版本的库，就是每个电脑中都使用同样的Podfile.lock，并且合理使用 pod install 和 pod update。
