一、 什么是Cocoapods
Cocoapods 是专门为xcode设计,用来管理第三方代码库的工具；所需的第三方依赖库，需要在Podfile文件里面进行配置。
许多人刚开始使用cocopods的时候，可能认为pod install 只是在首次配置自己项目的时候使用，pod update在以后使用，那么这样认为就大错特错了
二、 pod install vs. pod update 、pod outdated
-
pod install是用来安装一个新的pods依赖库，或者说pod install当你想把一个pods依赖移除或者添加到工程的时候使用； -
pod update仅仅是望你想要更新pods到较新版本的时候使用 - 当运行
pod install命令的时候，它的操作步骤是：下载和安装新的pods--- 在Podfile.lock文件写入每一个已经安装pods的版本号；这个文件用来追踪和锁定所安装的pods的版本号。 -
pod install仅仅处理那些没有在podfile.lock列出的依赖库pods。对于已经在Podfile.lock文件里的pods,它仅仅下载在Podfile.lock里面锁定的版本，并不去检查是否有可用的最新版本；对于没有在Podfile.lock的pods，它会搜索和匹配在Podfile文件里面所描述的对应的版本（e.gpod 'AFNetworking', '~>3.0')。 -
pod outdated命令Cocoapods会列出项目中Podfile.lock文件里面锁定的版本具有新版本可以更新的pods。
这个是我的工程里面对应的Podfile， 列出了工程需要的依赖库：
屏幕快照 2017-01-12 下午5.00.42.png
下面这个截图是pod outdated命令后，找出了有新版本可以更新的第三方库
屏幕快照 2017-01-12 下午5.01.16.png
下面的截图是Podfile.lock文件中锁定的第三方库的版本，以及对应的版本号
屏幕快照 2017-01-12 下午5.04.12.png
对比截图二和截图三，我们可以看出，在
Podfile.lock文件中，Masonry、SDWebImage、Realm这三个库锁定的版本号是比较老的版本，运行命令pod outdated后，就列出了可以更新的版本号。
-
pod update当你运行pod update podName,Cocoapods会找出podName 可以更新的的版本（除了在Podfile.lock里面已经列出锁定的版本）， 它会根据Podfile.lock文件里面的限制条件，尽可能对升级podName到比较新的可用的版本。如果pod update后面不添加podName的话，Cocoapods会根据Podfile文件里面列出的pods,把每一个pod更新到相应比较新的可用的版本。
三、 那么到底在那些场景下使用呢用呢？
- 对于
pod update PODNAME这个命令，仅仅是更新一个特定的pod(这个操作会根据Podfile文件的配置检测特定的pod是否存在可更新版本，如果就相应的进行更新）。与之相反的是命令pod install这个命令并不会尝试检测更新已经安装pod。 - 当你在
Podfile里面添加了新的pod，那么最好选择使用pod install，而不是选择pod update, 因为pod install可以避免安装和 更新操作在一个线程里面进行，从而提高效率，节省安装时间，但这并不是说pod update不行，而是相对来说这种场景下用pod install更好一些。 -
pod update命令，当你想要更新某一个特定的pod或者所有的pod的时候是最好的选择。
四、Commit 提交 Podfile.lock
作为一个提醒：即使你的代码管理策略中，提交代码的时候并不提交Pods文件夹到共享的代码仓库中，但是提交和上床Podfile.lock文件是很有必要的，否则的话，上面对于命令 pod install的功能解释（pod install可以安装锁定的相应版本）将不再适用。
五、适用场景举例
- 阶段一：用户
user1创建了一个工程
user1创建了一个工程，想使用pods A 、B 、C, 那么然后创建一个Podfile， 将对应的版本添加到Podfile里面，运行pod install, 将会安装 A、B、C，我们假设此时指定使用的版本都为1.0.0;
Podfile.lock将会持续追踪限制安装A、B、C的版本都为1.0.0；
此外：因为这是第一次运行
pod install命令， 此时Pods.xcodeproj并不存在， 那么运行pod install命令后，除了安装pods外，还会创建Pods.xcodeproj和.xcworkspace。
- 阶段2: 用户
user1添加了一个新的pod
不久后，user1想添加一个 pod D到Podfile文件。
这时运行pod install之后，即使这个时候对于pod B有一个 用于维护的Released 1.1.0版本，那么工程任然会保持pod B是版本1.0.0，因为用户user1 想要的是 pod D， 而不是其他版本的pod B。 - 阶段3： 用户
user2加入工程
对于user2加入这个团队之前从没用在这个工程工作过，他将会clone仓库并且pod install；
Podfile.lock文件的内容（这个内容应该是被提交到git 仓库的）将会保证user2获得的pod 和user1正在使用的pod是一样版本的pod；
即使现在对于pod C有一个1.2.0可用的版本，user2也只会安装使用 C1.0.0版本，这就要归功于Podfile.lock了， 因为 pod C在Podfile.lock中注册的版本是1.0.0，所以Podfile.lock就会锁定pod C只能安装使用1.0.0版本； - 阶段4： 检测新的可用pod
之后，user1 想知道那些pods更新了，那么可以运行pod outdated,Cocoapods将会列出有更新可用的pods, 比如 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 'A', '1.0.0'， 就可以保证所有团队成员可以使用相同的pod 版本，其实并不是这样。
有一个经典的例子：如果pod A有一个pod依赖 A2，并且在pod A的podspec中进行了声明：dependency 'A2', '~> 3.0'， 在这种场景下在Podfile文件中声明pod 'A', '1.0.0'确实能够保证user1和user2两者总是使用版本1.0.0，但是
-
user1可以使用 pod A2 3.4.0版本(在user1使用的时候假设A2 3.4.0版本是最新的可用） -
user2随后加入团队后，pod install获得的是 pod A2 3.5.0的版本（因为在user2的时候假设 3.5.0是可用的）
这就是为什么说使用Podfile.lock是唯一的途径让不同开发人员在不同的电脑上使用相同的pod的版本，并且要适当使用pod install和pod update。
