pod install和pod update – CocoaPods教程 _podupdate

上一章CocoaPods教程请查看：安装和使用CocoaPods
介绍许多以CocoaPods为起点的人似乎认为pod install只在你第一次使用CocoaPods设置项目时使用，而pod update则是在之后使用。但事实并非如此。
本指南的目的是解释什么时候应该使用pod install，什么时候应该使用pod update。
提示：

使用pod install在你的项目中安装新的pod。即你已经有一个Podfile，那么先运行pod install，所以，即使你只是添加/删除pod到一个项目，也是已经使用了CocoaPods。
仅当你想要将pod更新到新版本时，才使用pod update [PODNAME]。

命令的详细解释注意：install和update的命令实际上并不是特定于CocoaPods的。它受到了许多其他依赖项管理器的启发，比如bundler、RubyGems或composer，它们有类似的命令，行为和意图与本文档中描述的完全相同。
pod install
这将在你第一次为项目检索pod时使用，也将在你每次编辑Podfile以添加、更新或删除pod时使用。

每次运行pod install命令(以及下载和安装新pod)时，它都会将已安装的版本写入Podfile.lock文件中，该文件跟踪每个pod的安装版本并锁定这些版本。
当你运行pod install时，它只会解析Podfile.lock中未列出的pod的依赖项。
- 对于Podfile.lock中列出的，它将下载Podfile.lock中列出的显式版本，而不尝试检查是否有更新的版本可用。
- 对于Podfile.lock中没有列出的pod，它会搜索与Podfile中描述的匹配的版本(比如pod ‘ MyPod’ ， ‘ ~>1.2’ )

pod outdated
当你运行pod outdated时，CocoaPods会列出所有pod的更新版本，而不是Podfile.lock列出的版本(每个pod当前安装的版本)。这意味着如果你在这些pod上运行pod update PODNAME，它们将被更新——只要新版本仍然符合原来pod限制，如你的Podfile中设置的pod ‘ MyPod’ , ‘ ~>x.y’ 。
pod update
当你运行pod update PODNAME时，CocoaPods将尝试查找pod PODNAME的更新版本，而不考虑Podfile.lock中列出的版本。它将把pod更新到可能的最新版本(只要它符合你的Podfile中的版本限制)。
如果你运行pod update而没有pod名称，CocoaPods会将你的Podfile中列出的每个pod更新到可能的最新版本。
pod undate和pod install的使用使用pod update PODNAME，你将只能更新特定的pod(检查是否存在新版本并相应地更新pod)。与pod install不同，pod install不会尝试更新已经安装的pod版本。
当你将pod添加到你的Podfile时，你应该运行pod install，而不是pod update—安装这个新的pod而不必冒险在相同的过程中更新现有的pod。
你将仅在希望更新特定pod(或所有pod)的版本时使用pod install。
提交Podfile.lock提醒一下，即使你的策略是不将Pods文件夹提交到共享存储库中，你也应该始终提交并推送你的Podfile.lock文件。
否则，它将打破前面解释的pod install能够锁定你的pod安装版本的整个逻辑。
使用场景示例下面是一个场景示例，演示在项目生命周期中可能遇到的各种用例。
阶段1：User1创建项目
user1创建了一个项目，并希望使用pod A、B、C，他们用这些pod创建一个Podfile，然后运行pod install。
这将安装pod A,B,C，我们假设说它们都在1.0.0版本中。
Podfile.lock将跟踪这一点，并注意到A、B和C都安装为1.0.0版本。
顺便说一句，因为那是他们第一次运行pod install，Pods.xcodeproj项目还不存在，该命令还将创建Pods.xcodeproj和.xcworkspace，但这是该命令的一个副作用，而不是它的主要作用。
阶段2：User1添加一个新的pod
稍后，user1希望将pod D添加到他们的Podfile中。
之后要运行pod install，即使执行pod install也不会影响pod B的版本，该项目将继续使用版本1.0.0——因为user1只想添加pod D，也不用担心意外更新pod B。
这就是有些会出错的地方，因为他们在这里使用pod install—可能认为这是“我想用新的pod更新我的项目？”—而不是使用pod install – 在项目中安装新的pod。
阶段3：User2加入项目
然后user2，他以前从未参与过这个项目，加入了这个团队。他们克隆存储库，然后使用pod install。
Podfile.lock的内容(应该提交到git repo上)将保证它们获得完全相同的pod，具有与user1使用的完全相同的版本。
即使pod C的1.2.0版本现在可用，user2将在1.0.0版本中获得pod C，因为这是在podfile.lock中注册的，pod C被Podfile.lock锁定到1.0.0版本。
阶段4：检查pod的新版本
稍后，user1希望检查pod是否有可用的更新。他们运行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），但是会在1.0.0版本中保留pod C(不会更新到1.2.0)。
在Podfile中使用确切的版本是不够的有些人可能认为，通过在Podfile中指定pod的确切版本，比如pod ‘ A’ , ‘ 1.0.0’ ，就足以保证每个用户都拥有与团队中其他人相同的版本。
然后他们甚至可能使用pod update，即使只是添加一个新的pod，他们也会认为更新其他pod永远不会有风险，因为它们被固定到Podfile中的特定版本。
但实际上，这并不足以保证上面场景中的user1和user2将始终获得其所有pod的完全相同的版本。
一个典型的例子是，如果pod A依赖于在A中声明的pod A2。A.podspec作为依赖项’ A2’ ， ‘ ~> 3.0’ 。在这种情况下，在你的Podfile中使用pod ‘ A’ ， ‘ 1.0.0’ 确实会迫使user1和user2同时使用pod A的1.0.0版本，但是: