简介：
许多人开始使用 CocoaPods 的时候，似乎认为 pod install 仅仅被用于第一次你通过 CocoaPods 配置工程的时候；而之后都应该使用 pod update。但事实上事情并不是这样的。
这篇指导文章的目的，就是向你解释何时你应该使用 pod instal，何时你应该使用 pod update。

长话短说：
1、使用 pod install 来将新的 pod 安装到你的工程中。即使你已经有了一个 Podfile 并且之前运行过了 pod install；即便你只是向一个已经使用了 CocoaPods 的工程添加/移除 pods 你都应该使用 pod install。
2、仅仅当你想要将 pods 升级到更新的版本时，使用 pod update [PODNAME]。

详细讨论这两个命令：
注：install vs. update 实际上并不是专指 CocoaPods 的。这受到了许多其他依赖管理工具，像是 bundler（http://bundler.io/），RubyGems（https://rubygems.org/），或者 composer（https://getcomposer.org/）的影响。这些依赖管理工具都有着类似的命令，这些命令有着近乎一致的行为和作用，就像这篇文章中将要介绍的。

pod install
当你想要为你的工程加入 pods 时，这个命令第一次被使用；当然，任何时候你修改了你的 Podfile，添加，升级，或是移除一个 pod 时，你都应该使用这个命令。
1、当 pod install 命令运行的时候 —— 下载并安装新的 pods —— 他会将他所安装的每个 pods 的版本写到 Podfile.lock 文件中。这个文件（Podfile.lock）记录了每个 pods 的安装的版本并且将那些版本锁定住。
2、当你运行 pod install 的时候，它只会为那些还没有在 Podfile.lock 文件中列出的 pods 解决依赖问题。
a、对于那些记录在 Podfile.lock 文件中 pods ，CocoaPods 会通过在 Podfile.lock 中记录的明确的版本下载对应的 pods，不会尝试检查是否有更新的可用的版本
b、对于那些还没有被记录在 Podfile.lock 中的 pods，CocoaPods 会查找符合 Podfile 中所描述的版本的 pods （例如，pod 'MyPod','~>1.2'）

pod outdated
当你运行 pod outdated PODNAME，CocoaPods 会将那些对比记录在 Podfile.lock 中的版本（当前每个 pods 的安装版本）有更新版本的 pods 全部列出来。这意味着，如果你对那些 pods 运行 pod update PODNAME ，他们将会被更新 —— 只要那些新的版本符合你在 Podfile 中做的限制，就像 pod 'MyPod','_{>x.y'（例如，你的限制是‘}>1.2’，那么大于 1.2 的版本就都是可以更新的）

pod update
当你运行 pod update PODNAME 的时候，CocoaPods 将尝试寻找相应 PODNAME 的最新版本，而不会考虑记录在 Podfile.lock 文件中的 pod 版本。CocoaPods 会尽可能的将 pod 更新到最新的版本（只要这个最新的版本能满足 Podfile 中的限制）。
如果你直接运行 pod update 而没有指定 pod name，那么 CocoaPods 将会更新记录在 Podfile 中的所有 pod 到最新的版本。

用途：
通过 pod update PODNAME，你就能只更新一个指定的 pod （检查该 pod 是否存在新的版本，并由此更新 pod）。
相反的，运行 pod install 不会更新已经安装的 pods 的版本。
当你向你的 Podfile 添加了一个 pod，你应该运行 pod install，而不是 pod update —— 仅仅安装这个新的 pod，并且不在这个安装过程中冒险去更新已存在的 pod。
仅仅当你想去更新某一个指定的 pod（或者所有 pods）的版本的时候，你才会用到 pod update。
译者注：在你开发自己的 pod 时，往往会遇到向你的 pod 中添加 .h/.m/.xib 文件的情况，这个时候应该运行 pod install。原因是，在开发中的 pod 版本没有变化，但是内容发生了变化。运行 pod update 的话，由于版本没有发生变化，所以不会起效果。运行 pod install ，因为在开发中的 pod ，源代码文件往往是在你自己的电脑上，而后在 Podfile 中，这个开发中的 pod 的路径往往是 “../xxxpod” 这样的，在pod.project 中，这个正在开发的 pod 会存在于 development 文件夹下。运行 pod install 会将你新添加的 .h/.m/.xib 进行安装，如果不运行，会出现文件存在，但是Xcode 提示找不到文件的问题，原因就是上次 pod install 之后 CocoaPods 创建了 配置文件（.xcconfig，在 pods 文件目录下）。通过这些配置文件，CocoaPods 管理了所有的 pod 中的头文件路径，而新增的 .h/.m/.xib 不在原先的配置文件中，所以文件时存在的，但是 Xcode 找不到。

提交你的 Podfile.lock 文件：
你应该始终提交（commit）并推送（push）你的 Podfile.lock 文件到仓库（repository），哪怕你的策略是不将 Pods 文档提交到你的分享仓库。（https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control）
不然，这将会破坏整个逻辑 —— 上面所说的关于 pod install 能够将已经安装的 pods 的版本固定住的逻辑。

情景实例：
这有一个实际中的例子，它能说明多种使用场景，也许在你的工程开发中，会遇到这其中的一些。
1、User1 创建工程：
User1 创建了工程，并且想要使用 pods A,B,C。他创建了 Podfile 将这三个 pod 写入 Podfile，并运行了 pod install。
这将会安装 pod A,B,C ，我们假设这三个 pod 都是 1.0.0 版本。
然后 Podfile.lock 将会记录这一切，并且记录下 pod A,B,C 所安装的版本都是 1.0.0。
（附带的，由于这是第一次运行 pod install ，而且Pods. xcodeproj 工程还不存在，pod install 命令也将创建 Pods. xcodeproj 和 .xcworkspace，但这是 pod install 所附带的并不是他的主要作用）

2、User1 添加一个新的 pod：
之后，User1 想要添加一个新的 pod D 到 Podfile。
当他在 Podfile 中添加了 pod D 之后，紧接着他应该运行 pod install。这样一来，即便 pod B 的维护者，在 User1 第一次执行 pod install 之后，发布了 pod B 的 1.1.0 版本，工程中仍会继续使用 pod B 的 1.0.0 版本 —— 因为 User1 只想添加 pod D，不想冒险升级 pod B。
这儿就是一些人错误认识的地方，因为他们在这里使用 pod update —— 他们可能是这样想的 “我想用新的 pods 更新我的工程” —— 替代使用 pod install ，来向工程安装新的 pod。

3、User2 加入工程：
然后 User2 加入了团队，之前 User2 从未参与过该工程。他们 clone 了仓库，然后运行 pod install。
Podfile.lock（该文件应该提交到 git 仓库） 的内容，将会保证他们能得到完全相同的 pods，pods 的版本完全和 User1 所使用的一致。
即便 pod C 有一个 1.2.0 版本可以使用，User2 仍然会得到 1.0.0 版本的 pod C。因为在 Podfile.lock 中注册的就是 1.0.0 版本。pod C 被 Podfile.lock 锁定在 1.0.0 版本。

4、检查一个 pod 的新版本：
之后，User1 想要检查下所安装的 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），而保持 pod C 的版本在 1.0.0（并不会把他更新到 1.2.0）

在 Podfile 中使用准确的版本是不够的：
一些人可能认为，在 Podfile 中为他们的 pods 指定准确的版本，像是 pod ‘A’，‘1.0.0’，就足以每一个用户，都像保证团队中的其他人一样，能够获得相同的版本。
接着，在添加一个新的 pod 的时候， 他们使用 pod update。他们认为这将不会造成任何风险 —— 不会更新其他 pods，因为这些 pods 在 Podfile 中被固定在了指定的版本上。
但事实上，在我们上述的例子中，这不足以保证 User1 和 User2 他们所得到的 pods 的版本是一致的。
一个典型的例子是，pod A 有一个对 pod A2 的依赖 —— 申明在 A. podspec ，就像 dependency 'A2', '~> 3.0' 这样。在这种情况下，在你的 Podfile 中使用 pod 'A', '1.0.0' 将确实会强制 User1 和 User2 总是使用 pod A 的 1.0.0 版本，但是：
User1 可能使用的是 pod A2 的 3.4 版本（因为在 User1 运行 pod install 的时候，pod A2 的最新版本是 3.4）
而当 User2 运行 pod install 时，因为是在后来加入工程的，他们可能得到的是 pod A2 的 3.5 版本（因为，A2 的维护者可能在此期间发布了新的版本）
这就是为什么，唯一能确定所有组员，在他们的电脑上所用的所有 pod ，都使用了一致的版本的方法，是通过 Podfile.lock。同时，正确运用 pod install 和 pod update。