引言
许多人在最初接触CocoaPods时认为pod install只是在第一次为项目设置CocoaPods时使用，之后都应该使用pod update.看起来是这样，但也不是（But that's not the case at all.）。
这篇文章的目的就是教你啥时候用pod install,啥时候用pod update
名词解释
pod：本文中指某一个第三方库，理解为一个软件或插件就好
pods：pod的复数
摘要：
- 使用pod install下载新的pods到你的项目，即使你已经有了一个Podfile文件并且之前使用过pod install命令；当你需要增加或移除某一个或多个pods时，你需要使用pod install
- pod update [PODNAME]仅仅用在你想要更新这个pods的版本时，不指定PODNAME会自动遍历所有pods。
命令详细介绍
注意：install和update的区别不是CocoaPods特有的，这个灵感来自于很多其他的依赖管理工具，像bundler,RubyGems还有composer,他们都有类似的命令表示和这篇文章提到的类似行为和意图
pod install
这个命令不仅仅用于第一次为项目下载pods，之后的开发过程中，如果有需要增加，更新或者移除pod，也需要使用它。
- 每一次执行pod install命令-下载安装新的pods-每一个pod的版本都会被记录在Podfile.lock文件中。这个文件追踪每个pod的安装版本并且将它锁定。
- 当你使用pod install时，它只是解决了之前未列入Podfile.lock的文件中的pods的依赖关系。
- 对于那些已经出现在Podfile.lock文件中的pods，它只会下载该文件中指定版本的pod，并不会去检索是否存在新的版本
- 对于Podfile.lock文件中还没有锁住版本的新增pod，它会按照Podfile文件中描述的方式去搜索匹配的版本。
pod outdated
当你使用pod outdated，CocoaPods会帮你把Podfile.lock文件中有新的版本的可供更新的pod列出来，这就表示你使用pod update PODNAME就可以更新这些pod，前提是这个新的版本同样符合你在Podfile中所设的版本约束。
pod update
当你使用pod update PODNAME，CocoaPods会去找到指定PODNAME的更新，不再从Podfile.lock列表中的版本作比对，它会尽可能的更新到最新版本（前提是新版本和你在Podfile中所设的约束匹配）。
如果你使用pod update,不指定pod名，CocoaPods将遍历你在Podfile中列出来的所有pods到符合约束的最新版本
用途
使用pod update PODNAME,你可以更新指定的pod（检索到符合约束的可更新的版本存在，会更新它）。相反pod install并不会更新已安装过的pods到新版本。
当你增加一个pod到你的Podfile，你应该使用Pod install，而不是pod update（在安装新的pod同时冒险更新了已存在的pod）。
pod update [PODNAME]仅该被用在你想要更新某个pod的版本时（或者是所有版本）
提交你的Podfile.lock
建议情况下，即使你决定不提交Pods的文件夹到共享仓库，你也应该提交（commit&push）你的Podfile.lock文件。
否则，pod install可以锁住版本的逻辑就不成立
情景示例
- 情景1:用户1创建项目
用户1创建了项目，想要安装pods A，B，C，创建一个Podfile文件，使用pod install
这里将会安装A，B，C，版本都是1.0.0。
Podfile.lock会跟踪版本，A，B，C的版本都会锁定为1.0.0。
顺便提一句，因为这里是第一次使用Pod install，所以CocoaPods还会创建Pods.xcodeproj 和 .xcworkspace文件，但这不是主要功能 - 情景2:用户1增加新的pod
稍后，用户1想要增加pod D到Podfile中，
这里也应该使用pod install，所以，虽然这里pod B的开发者在这之间更新了一个新的版本1.1.0，这个项目依然会使用1.0.0，因为用户1只想增加pod D，而不想更新pod B
这里就是很多用户出错的地方，他们在这里使用了pod update（表示我想更新项目到新的版本）而不是pod install（增加新的pod到项目中） - 情景3:用户2加入项目
用户2，第一次加入项目中，克隆了项目仓库，并使用pod install。
Podfile.lock（应该被提交到git repo）中的内容将确保他得到和用户1使用的版本相同的pod。
即使这时pod C有1.2.0可用，用户2得到的还是1.0.0，因为在Podfile.lock中锁住的是它 - 情景4:检查新的版本更新
过后，用户1想检查是否有更新，他使用pod outdated告诉他某些pod B可用1.1.0，pod C可用1.2.0.
用户1决定更新podB，pod C不更新，他使用pod update B更新pod B到版本1.1.0（这是poflie.lock也会这样更新），但是pod C还是1.0.0。
使用固定版本在Podfile中是不够的
有的人可能觉得，我在Podfile中使用精确的固定版本，例如pod ‘A’, ‘1.0.0’,是不是可以确保我团队的所有成员使用的都是同一个版本。
他们也使用pod update,这次只会增加新的pod，认为它不会有任何更新其它pods的风险，因为版本已经被指定了。
但实际上，这不能确保我们上面示例中的用户1和用户2获得的所有pods版本都一致。
典型的例子是如果pod A依赖于pod A2（在A.podspec中声明：dependency ‘A2’, ‘～> 3.0’）。这种情况下，在你的Podfile中使用pod ‘A’, ‘1.0.0’*将强制用户1和用户2使用podA的1.0.0版本，但是：
- 用户1使用的pod A2可能是版本3.4（因为用户1使用是这是它的最新版本）
- 当用户2之后加入项目使用pod install时，pod A2的版本可能变成了3.5（因为A2的开发者在这期间更新了）
这就是为什么确保团队每个成员使用在不同电脑使用同一版本的唯一方式时使用Podfile.lock并且适当使用pod install和pod update
关于版本指定约束
- pod ‘SSZipArchive’
不指定版本，表示希望使用最新版本 - pod 'Objection', '0.9'
指定明确版本，表示只想要这个版本 - 逻辑关系
- '> 0.1' 版本号大于0.1的
- ‘>= 0.1’ 版本0.1和版本号大于0.1的
- '< 0.1' 版本号小于0.1的
- ‘<= 0.1' 版本号0.1和版本号小于0.1的
- 最优匹配
- ‘~> 0.1.2' 版本0.1.2和版本号处于0.1.2-0.2之间的,不包括0.2和更高版本
- ‘~> 0.1' 版本0.1和版本号处于0.1-1.0之间的,不包括1.0和更高版本
- ‘~> 0' 版本0和更高，和没设没啥区别
