pod install一般是你第一次想要为项目添加pod的时候使用，也可以在你位podfile文件和移除pod库的时候使用
每次pod install命令时候，pod install会为每一个他安装的pod库在podfile.lock文件中写入版本号。podfile.lock文件追踪每一个安装的pod库的版本号，并锁定这些版本号
当你运行pod install时，他只解决不在podfile.lock中的pod库的依赖关系
对于在podfile.lock文件中的pod库，podinstall只会下载podfile.lock文件中指定的版本，而不会去检查这个库是否有新的更新
对于不在podfile.lock文件中的pod库，podinstall会搜索这个pod库在podfile文件中指定的版本
pod update
当你运行pod update命令时候，cocopods会列出所有在podfile.lock中有新版本的pod库，这意味着，你对这些库使用pod update时候，它们会更新
当你向podfile中添加或者删除 pod，你应该使用pod install而不是pod update来
当想更新某个特定的pod库的版本时候，需要使用pod update
执行pod install命令，会搜索pod库相匹配的版本，并添加到podfile.lock内，保存版本，
当你使用pod update,pod会把所有podfile.lock内有新版本的pod库都列出来，这表示你使用pod update就可以更新这些库，前提是这些新版本符合你在podfile中所设的版本约束
使用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 updated告诉他某些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和更高，和没说没啥区别
