简介

许多以CocoaPods开头的人似乎认为pod install只在第一次使用CocoaPods设置项目时使用，pod update之后才会使用。但事实并非如此。

本指南的目的是解释何时使用pod install以及何时使用pod update。

TL; DR：

  • 使用pod install以安装新的吊舱在您的项目。即使你已经拥有Podfile并跑pod install过去 ; 所以，即使你只是在已经使用CocoaPods的项目中添加/删除pod。
  • 使用pod update [PODNAME]只有当你想更新荚到新版本。

命令的详细介绍

注意：installvs 的词汇update实际上并不特定于CocoaPods。它的灵感来自许多其他依赖管理器，如bundler，RubyGems或composer，它们具有类似的命令，具有与本文档中描述的完全相同的行为和意图。

pod install

这是在您第一次要检索项目的pod时使用，也是每次编辑Podfile以添加，更新或删除Pod时使用。

  • 每次pod install运行命令 - 并下载并安装新的pod时 - 它会为Podfile.lock文件中的每个pod写入已安装的版本。此文件跟踪每个pod的已安装版本并锁定这些版本。
  • 当您运行pod install，它只是解决了那些荚依赖不是已经上市Podfile.lock。
  • 对于列出的pod Podfile.lock，它会下载显示的显式版本，Podfile.lock而不尝试检查是否有更新的版本
  • 对于尚未列出的pod 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时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 创建一个并运行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添加新pod

之后，user1想要将pod添加D到其中Podfile。

因此它们应该在pod install之后运行，因此即使pod的维护者在第一次执行后B发布了1.1.0其pod 的版本pod install，该项目将继续使用版本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.0的pod C，user2也会获得C版本的pod 1.0.0。因为这是注册的Podfile.lock。吊舱C被锁定到版本1.0.0由Podfile.lock（该文件因此得名）。

阶段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）但将保持pod C版本1.0.0（并且不会将其更新为1.2.0）。

使用中的确切版本Podfile是不够的

有些人可能会认为，通过在其指定的豆荚确切的版本Podfile，像pod 'A', '1.0.0'，就足以保证每一个用户都会有相同的版本与其他人的团队。

然后他们甚至可以使用pod update，即使只是添加一个新的pod，认为它永远不会冒更新其他pod的风险，因为它们被固定到了一个特定的版本Podfile。

但事实上，这还不足以保证我们上面场景中的user1和user2将始终获得所有pod的完全相同的版本。

一个典型的例子是pod如果对pod A有依赖A2- 在A.podspecas中声明dependency 'A2', '~> 3.0'。在这种情况下，pod 'A', '1.0.0'在你的Podfile遗嘱中使用确实迫使user1和user2都使用1.0.0pod的版本A，但是：

  • user1最终可能会A2以版本中的pod结尾3.4（因为那时是A2最新版本）
  • 当user2pod install在以后加入项目时运行时，他们可能会A2在版本中获得pod 3.5（因为维护者A2可能在此期间发布了新版本）。

这就是为什么确保每个团队成员使用每台计算机上所有pod的相同版本的唯一方法是使用Podfile.lock和正确使用pod installvs pod update.。