pod安装与pod更新
pod安装与pod更新
<简介
许多以CocoaPods开头的人似乎认为pod install，仅在您第一次使用CocoaPods设置项目时才pod update使用，然后才使用。但这不是事实。
本指南的目的是说明何时应使用pod install以及何时应使用pod update。
TL; DR：
使用pod install以安装新的吊舱在您的项目。即使你已经有一个Podfile和跑pod install前 ; 因此，即使您只是将吊舱添加/删除到已经使用CocoaPods的项目中。
使用pod update [PODNAME]只有当你想更新荚到新版本。
<命令的详细介绍
注意：installvs. 的词汇update实际上并非特定于CocoaPods。它的灵感来自于许多其他依赖项管理器，例如bundler，RubyGems或composer，它们具有相似的命令，其行为和意图与本文档中所描述的完全相同。
<pod install
这是在第一次要检索项目的Pod时使用，也每次在您编辑Podfile以添加，更新或删除Pod时使用。
每次运行该pod install命令（并下载并安装新的Pod）时，它将为每个Pod写入已安装的版本Podfile.lock。该文件跟踪每个Pod的安装版本，并锁定这些版本。
当您运行时pod install，它仅解决尚未在中列出的Pod的依赖关系Podfile.lock。
对于中列出的Pod Podfile.lock，它将下载中列出的显式版本，而Podfile.lock不会尝试检查是否有较新的版本
对于Podfile.lock尚未在列表中列出的广告连播，它会搜索与中描述的内容相匹配的版本Podfile（如中的pod 'MyPod', '~>1.2'）
<pod outdated
当您运行时pod outdated，CocoaPods会列出所有具有比Podfile.lock（列出的当前为每个Pod安装的版本）版本更高的Pod。这意味着，如果您pod update PODNAME在这些Pod上运行，它们将被更新—只要新版本仍符合pod 'MyPod', '~>x.y'您在中设置的限制Podfile。
<pod update
当您运行时pod update PODNAME，CocoaPods会尝试查找pod的更新版本PODNAME，而不考虑列出的版本Podfile.lock。它将把Pod更新到可能的最新版本（只要它符合您中的版本限制Podfile）。
如果您pod update没有运行Pod名称，CocoaPods会将您列出的每个Pod更新Podfile为可能的最新版本。
<预期用途
使用pod update PODNAME，您将只能更新特定的Pod（检查是否存在新版本并相应地更新Pod）。与之相反pod install，它将不会尝试更新已安装的pod的版本。
当您将Pod添加到自己的Pod中时Podfile，您应该运行pod install，而不是pod update-安装此新Pod，而不必冒险在同一过程中更新现有Pod。
仅pod update在要更新特定容器（或所有容器）的版本时才使用。
<提交您的Podfile.lock
提醒您Pods，即使您的政策是不将文件夹提交到共享存储库中，也应始终提交并推送Podfile.lock文件。
否则，它将破坏上面解释的有关pod install能够锁定Pod的已安装版本的整个逻辑。
<场景示例
这是一个场景示例，用于说明一个人在项目生命周期中可能遇到的各种用例。
<阶段1：User1创建项目
USER1创建一个项目，想用荚A，B，C。他们Podfile用这些吊舱创建一个，然后运行pod install。
这将安装吊舱A，B，C，我们会说都在版本1.0.0。
该Podfile.lock会持续跟踪并注意A，B并C在每个已安装的版本1.0.0。
顺便说一句，因为这是它们的第一次运行，pod install并且该Pods.xcodeproj项目尚不存在，所以该命令还将创建Pods.xcodeproj和.xcworkspace，但这是该命令的副作用，而不是其主要作用。
<阶段2：User1添加了一个新容器
稍后，user1想要将pod添加D到其中Podfile。
因此pod install，它们应该随后运行，以便即使pod的维护者自第一次执行以来就B发布了1.1.0其pod 的版本pod install，该项目仍将继续使用version 1.0.0，因为user1只想添加pod D，而不会冒意外更新pod的风险B。
那是一些人弄错的地方，因为他们pod update在这里使用-可能会认为这是“我想用新的Pod 更新我的项目 ”？（而不是使用）pod install在项目中安装新的Pod。
<阶段3：User2加入项目
然后，从未在该项目上工作过的user2加入该团队。他们克隆存储库，然后使用pod install。
的内容Podfile.lock（应提交到git仓库）将保证他们将获得完全相同的豆荚，用完全相同的版本的USER1使用。
即使1.2.0pod 的版本C现在可用，user2也会C在version中获得pod 1.0.0。因为那是在中注册的内容Podfile.lock。吊舱C被锁定到版本1.0.0由Podfile.lock（该文件因此得名）。
<阶段4：检查广告连播的新版本
以后，user1要检查是否有任何更新可用于吊舱。他们运行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（例如）中指定其pod的确切版本pod 'A', '1.0.0'就足以保证每个用户与团队中其他人的版本相同。
然后pod update，即使只是添加新的Pod，他们甚至可能会使用，以为永远不会冒着更新其他Pod的风险，因为它们已固定到中的特定版本Podfile。
但是实际上，这还不足以保证在我们上面的场景中，user1和user2始终会获得其所有pod的完全相同的版本。
一个典型的示例是，如果pod A依赖于pod A2—声明A.podspec为dependency 'A2', '~> 3.0'。在这种情况下，使用pod 'A', '1.0.0'in Podfile确实会强制user1和user2都始终使用1.0.0pod的版本A，但是：
user1可能会以Pod A2版本结束3.4（因为这是当时A2的最新版本）
当user2pod install在以后加入项目时运行时，他们可能会获得Pod A2版本3.5（因为的维护者同时A2可能已发布了新版本）。
这就是为什么只有这样才能保证所有的吊舱的相同版本的每一位团队成员的工作在每个电脑是使用Podfile.lock和正确使用pod install与pod update。
pod安装与pod更新
