pod install
在项目中第一次使用CocoaPods, 进行安装的时候使用这个命令.
在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发生版本不一样的情况, 而导致出现函数找不到或者其他的错误.
场景示例
user1创建了项目
user1创建了一个项目, 并且想用A, B, C这3个pod库, 这个时候用pod install安装了这些pod库, 并且假设这3个库的版本号都是1.0.0, 这些版本号等信息会记录在Podfile.lock文件中.
user1添加了新的pod
根据项目的进度需求, 添加了D这个pod库到项目中, 这个时候应该使用pod install去安装D这个库到项目中, 即使在添加D这个库之前, B的版本被维护者更新到了1.1.0, 使用pod install也只会安装D这个库到项目中, 而不会去帮你更新B的版本. 从而不会出现因为B的版本更新后, 假如某些函数过期了, 或者某些函数被移除了, 而导致你被迫需要修改项目代码.
user2加入到项目中
假设团队中新增加了一位基友user2, 他克隆了项目, 并且pod install. (前提是你没有把Pods目录添加到源代码管理中), 如果你将Podfile.lock提交到了版本控制. 那么基友安装后的pod会和你的一模一样, 不会出现他的pod版本比你的高. 即便现在C的版本更新到了1.2.0, 基友安装的也是1.0.0版本. 因为在Podfile.lock中记录的pod C就是1.0.0版本.
检查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