正确的使用pod install 和 pod update - CocoaPods

pod install

1. 在项目中第一次使用CocoaPods, 进行安装的时候使用这个命令.
2. 在Podfile中增长或删除某个pod后, 也是使用这个命令. 而不是pod update.

• 每次运行pod install命令, 下载并安装新的pod时, 它会为Podfile.lock文件中的每一个pod写入已安装的版本. 此文件跟踪每一个pod的已安装版本并锁定这些版本(.lock命名所以而来).

• 当运行pod install，它只解析Podfile.lock中还没有列在其中的pod的依赖库.

  • 对于已经在Podfile.lock中列出的pod, Podfile.lock不会尝试检查是否有更新的版本.
  • 对于还没有在Podfile.lock中列出的pod, 会搜索与Podfile（如中所述pod 'MyPod', '~>1.2'）匹配的版本或最新的版本.

注: 第一次运行pod install的时候, .xcworkspace项目和Pods目录还不存在, pod install命令也会建立.xcworkspace和Pods目录, 但这是pod install命令的顺带做用，而不是它的主要做用.

pod outdated

当运行pod outdated时, CocoaPods将列出全部比Podfile.lock（每一个pod当前安装的版本）中, 已经列出的版本更新的pod版本. 这意味着若是你在这些pod上运行pod update PODNAME, 它将会把指定的pod更新到最新版本.

pod update

当运行pod update PODNAME时, CocoaPods将尝试查找PODNAME更新的pod版本, 会忽略掉Podfile.lock中已经存在的版本.

若是直接运行pod update, 没有指定PODNAME, CocoaPods会把Podfile中全部的pod都更新到最新版本.(若是已是最新版本了, 则不更新)

预期用途

使用pod update PODNAME, 将只能更新特定的pod(检查是否存在新版本并相应地更新pod). 相反, pod install不会尝试更新已安装的pod的版本.

当向Podfile中添加一个pod时, 应该运行pod install, 而不是用pod update来安装这个新pod.

只有在想要更新特定pod（或全部的pod）的版本时才会使用pod update.

必须提交的Podfile.lock

有时候可能你不想提交Pods目录到源代码管理中. 可是在多人开发的状况下, 必定要提交Podfile.lock这个文件, 由于这个文件里面记录了你的Podfile中全部pod的版本信息. 为避免你的Podfile中的pod版本和别人的Podfile中的pod发生版本不同的状况, 而致使出现函数找不到或者其余的错误.

场景示例

1. user1建立了项目

user1建立了一个项目, 而且想用A, B, C这3个pod库, 这个时候用pod install安装了这些pod库, 而且假设这3个库的版本号都是1.0.0, 这些版本号等信息会记录在Podfile.lock文件中.

1. user1添加了新的pod

根据项目的进度需求, 添加了D这个pod库到项目中, 这个时候应该使用pod install去安装D这个库到项目中, 即便在添加D这个库以前, B的版本被维护者更新到了1.1.0, 使用pod install也只会安装D这个库到项目中, 而不会去帮你更新B的版本. 从而不会出现由于B的版本更新后, 假如某些函数过时了, 或者某些函数被移除了, 而致使你被迫须要修改项目代码.

1. user2加入到项目中

假设团队中新增长了一位基友user2, 他克隆了项目, 而且pod install. (前提是你没有把Pods目录添加到源代码管理中), 若是你将Podfile.lock提交到了版本控制. 那么基友安装后的pod会和你的如出一辙, 不会出现他的pod版本比你的高. 即使如今C的版本更新到了1.2.0, 基友安装的也是1.0.0版本. 由于在Podfile.lock中记录的pod C就是1.0.0版本.

1. 检查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确切的版本, 像pod 'A', '1.0.0', 就足以保证每个人和其余人都会有相同的版本. 而后他们甚至可使用pod update, 即便只是添加一个新的pod, 认为它永远不会有更新其余pod版本的风险, 由于它们在Podfile中被固定到了一个特定的版本.

但事实上, 这还不足以保证咱们上面场景中的user1和user2, 始终得到全部pod的彻底相同的版本. 举一个典型的例子, 若是pod A中有对pod A2的依赖, 在A.podspecas中声明dependency 'A2', '~> 3.0'. 在这种状况下，pod 'A', '1.0.0'在你的Podfile中使用的时候, 确实会强制user1和user2始终使用A 1.0.0 的pod版本.

可是: user1最终可能获取到的A2版本是pod 3.4(由于那时A2是最新版本), 当user2在之后加入项目时运行pod install, 他可能会在A2的版本中得到pod 3.5(由于维护者A2可能在此期间发布了新版本).

这就是为何为了确保在每一个团队成员使用的每台电脑上, 全部相同的pod版本的惟一方法, 是使用Podfile.lock和正确使用pod install和pod update的缘由.

我应该将Pods目录添加到源代码管理中吗？

是否将Pods文件夹添加到源代码管理中都取决于你，由于工做流程因项目而异. 咱们建议您将Pods目录保留在源代码管理下, 不要将其添加到您的.gitignore. 但最终这个决定取决于你:

添加Pod目录的好处

• 克隆了repo后, 即便没有在机器上安装CocoaPods, 项目也能够当即构建和运行. 无需运行pod install, 也无需Internet链接.
• Pod（代码/库）老是可用的, 即便Pod的源（例如GitHub）要关闭也是如此.
• 在克隆repo后, Pod组件保证与原始安装中的组件相同.

忽略Pods目录的好处

• 源代码仓库将更小, 而且占用更少的空间.
• 只要全部Pod的源（例如GitHub）均可用, CocoaPods一般可以从新建立相同的安装.（从技术上讲, 没法保证pod install在Podfile中不使用提交SHA时, 运行将获取并从新建立相同的组件. 在Podfile中使用zip文件时尤为如此.）
• 执行源控制操做时不会有任何冲突, 例如合并具备不一样Pod版本的分支.

不管你是否在忽略Pods目录, Podfile并Podfile.lock应始终版本控制下保持.

原文地址: 点击直达

本文内容来源:
https://guides.cocoapods.org/using/pod-install-vs-update.html
https://guides.cocoapods.org/using/using-cocoapods.html