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发生版本不一样的情况, 而导致出现函数找不到或者其他的错误.
场景示例
1.user1创建了项目
user1创建了一个项目, 并且想用A,B,C这3个pod库, 这个时候用pod install安装了这些pod库, 并且假设这3个库的版本号都是1.0.0, 这些版本号等信息会记录在Podfile.lock文件中.
2.user1添加了新的pod
根据项目的进度需求, 添加了D这个pod库到项目中, 这个时候应该使用pod install去安装D这个库到项目中, 即使在添加D这个库之前,B的版本被维护者更新到了1.1.0, 使用pod install也只会安装D这个库到项目中, 而不会去帮你更新B的版本. 从而不会出现因为B的版本更新后, 假如某些函数过期了, 或者某些函数被移除了, 而导致你被迫需要修改项目代码.
3.user2加入到项目中
假设团队中新增加了一位基友user2, 他克隆了项目, 并且pod install. (前提是你没有把Pods目录添加到源代码管理中), 如果你将Podfile.lock提交到了版本控制. 那么基友安装后的pod会和你的一模一样, 不会出现他的pod版本比你的高. 即便现在C的版本更新到了1.2.0, 基友安装的也是1.0.0版本. 因为在Podfile.lock中记录的podC就是1.0.0版本.
4.检查pod的新版本
后来, user1想要检查下是否有更新pod的版本. 运行pod outdated, 会告诉你podB有一个新1.1.0版本, podC已经是1.2.0版本. user1决定他想要更新podB, 但不更新podC. 因此, 他会运行pod update B, 将B从1.0.0版本更新到版本1.1.0（并相应的更新Podfile.lock）, 但会将podC保留在版本中1.0.0(不会将其更新为1.2.0).
使用指定版本的Podfile是不够的
有些人可能会认为, 通过在Podfile中指定pod确切的版本, 像pod 'A', '1.0.0', 就足以保证每一个人和其他人都会有相同的版本. 然后他们甚至可以使用pod update, 即使只是添加一个新的pod, 认为它永远不会有更新其他pod版本的风险, 因为它们在Podfile中被固定到了一个特定的版本.
但事实上, 这还不足以保证我们上面场景中的user1和user2, 始终获得所有pod的完全相同的版本. 举一个典型的例子, 如果podA中有对podA2的依赖, 在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的版本中获得pod3.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应始终版本控制下保持.
######################################################################
命令的详细介绍
pod install
pod install一般是你第一次想要为项目添加pod的时候使用的，它同样也使用在你为Podfile文件添加或移除pod库的时候。
每次pod install命令运行的时候，pod install会为每一个它安装的pod库在Podfile.lock文件中写入其版本号。Podfile.lock文件追踪每一个安装的pod库的版本号，并锁定这些版本号。
当你运行pod install是，它将只解决不在Podfile.lock中的pod库依赖关系
对于在Podfile.lock文件中的pod库，pod install会只下载Podfile.lock文件中指定的版本，而不会去检查这个库是否有更新的版本。
对于不在Podfile.lock文件中的pod库，pod install会搜索这个pod库在Podfile文件中指定的版本(没指定版本，就搜索这个pod库最新的版本)
pod outdated
每当你运行pod outdated命令时，CocoaPods会列出所有在Podfile.lock中的有新版本的pod库。这意味着当你对这些pod使用pod update PODNAME时，他们会更新（只要新版本仍然遵守你在Podfile中做的类似于pod 'MyPod', '~>x.y'这样的限制）
pod update
当你运行了pod update PODNAME命令，CocoaPods会在不考虑Podfile.lock中版本的情况下试着去查找PODNAME的最新版本（当运行pod update PODNAME时, CocoaPods将尝试查找PODNAME更新的pod版本, 会忽略掉Podfile.lock中已经存在的版本.）（Podfile.lock文件中的每个pod写入已安装的版本. 此文件跟踪每个pod的已安装版本并锁定这些版本）。pod update PODNAME命令会将相应的pod更新到最新的版本（新版本仍然遵守你在Podfile中做的限制）
用法
通过pod update PODNAME,你可以只更新某个特定的pod库（检查是否存在新版本并更新相应的pod库）。相反，pod install则不会去更新已安装的pod库。
当你向Podfile中添加了pod，你应该使用pod install而不是pod update去在不更新已安装的pod库的版本基础上安装新添加的pod库。
当你想过更新某个特定pod库（或所有的库）的版本时你只需要使用pod update
提交你的Podfile文件
提醒一下，即使你没有把Pods文件夹提交到你的共享仓库，你都应该总是commit并push你的Podfile.lock文件。否则的话，将会破坏pod install能够锁定pod库的已安装版本的整个逻辑（如上面所说的那样） 。 有时候可能你不想提交Pods目录到源代码管理中. 但是在多人开发的情况下, 一定要提交Podfile.lock这个文件, 因为这个文件里面记录了你的Podfile中所有pod的版本信息. 为避免你的Podfile中的pod版本和别人的Podfile中的pod发生版本不一样的情况, 而导致出现函数找不到或者其他的错误.
在Podfile中使用确定的版本是不够的
有人认为通过在Podfile中为pod指定确定的版本就足够保证所有的用户都会拥有相同的版本。
随后他们可能会只使用pod update（即使是在添加一个新pod时），并且认为这将不会更新其他pod库版本，因为已经在Podfile中指定了确定的版本。
但是事实上，这样做不能够保证用户1和用户2总是取得完全相同的pod库版本。
一个典型的例子是，如果pod A依赖于podA2（通过在A.podspec中的dependency 'A2', '~> 3.0声明的）。在这种情况下，在你的Podfile中使用pod 'A', '1.0.0'的确会强制用户1和用户2总是使用podA的1.0.0版本，但是：
用户1可能会使用A2的3.4版本
同时当随后加入项目的用户2运行了pod install命令，他可能会得到podA2的3.5版本（因为A2的维护者可能发布了一个新的版本）
这就是为什么唯一能够保证团队中所有的成员都用使用pod库的相同版本的方法就是使用Podfile.lock并且正确的使用pod install和pod update
网友评论