pod install和pod update的区别以及各自使用场

简介

大多数人使用CocoaPods的时候都会想当然的以为pod install仅仅在第一次初始化项目的时候使用，pod update在接下来的更新中使用，事情并非如此。

接下来的文章将向你介绍合适使用pod install 何时使用 pod update.

• pod install用在第一次在你的项目中安装pods的时候，即使已经存在Podfile文件或者之前进行过pod install.
• pod update 一般在你想要更新pods到一个新的版本的时候使用。

命令的详细说明

注意：install 和 update并不仅仅在CocoaPods中使用，它其实是受到很对以来管理器的启发（比如： bundler, RubyGems or composer），同样具有类似的命令。

pod install

这个命令常常用在你第一次你为项目添加pods时使用，当然在你编辑了你的pod文件用来添加、更新或者删除依赖时也可使用。

• 每次当pod install 命令运行，并下载安装新的pods的时候，他会在Podfile.lock中为每个pod写入它安装的版本。此文件跟踪每一个已安装的版本，并且锁定这些版本。
• 当运行pod install 的时候它仅仅解析那些Podfile.lock中位列出的依赖关系。
  • 对于Podfile.lock中列出的pods，它仅仅会下载指明的版本，不会去检查是否有新版本可用。
• 对于Podfile.lock中未列出的pods，他会搜索与Podfile中内容相匹配的版本 (例如 pod 'MyPod', '~>1.2')。

pod update

当运行pod update PODNAME时，CocoaPods将尝试查找PODNAME的更新版本，而不考虑Podfile.lock中列出的版本。 它会将pod更新为可能的最新版本（只要它与Podfile中的版本限制相匹配）。

如果运行pod更新没有pod名称，CocoaPods将更新您Podfile中列出的每个pod到最新的版本。

pod outdated

当运行pod过时时，CocoaPods将列出所有具有比Podfile.lock中列出的版本更高版本的pod（当前为每个pod安装的版本）。 这意味着如果您在这些pod上运行pod update PODNAME，它们将被更新 - 只要新版本仍然匹配像您在Podfile中设置的“MyPod”，“〜> x.y”这样的限制。

预期使用

使用pod update PODNAME，您将只能更新特定的pod（检查是否存在新版本并相应地更新pod）。 与pod安装相反（不会尝试更新已安装的pod的版本）。

当您将Pod添加到Podfile时，您应该运行pod install而不是pod update - 来安装此新的pod，而无需在同一个进程中更新现有的pod。

只有当您要更新特定pod（或所有pods）的版本时，才会使用pod update。

提交你的Podfile.lock

作为提醒，即使您的策略不是将Pods文件夹提交到共享存储库，您应该始终提交并推送Podfile.lock文件。

否则，它将破坏上面解释的关于pod安装能够锁定您的pod的已安装版本的整个逻辑。

场景示例

这里是一个场景示例，以说明在项目生命期间可能遇到的各种用例。

• 阶段1：User1创建项目

• user1创建一个项目并要使用pod A，B，C。 他们使用这些pod创建一个Podfile，并运行pod install。

• 这将安装pod 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

• 因此，接下来他们应该运行pod install，即使pod B的维护者从第一次执行pod install以来发布了它们的pod的1.1.0版本，该项目将继续使用1.0.0版本 - 因为user1只想添加 pod D，而不会有冒险更新到pod B。

这也许是大部分人错误使用pod update的原因（他们也许认为我仅仅是想跟新一个pod，而不是重新在项目中安装一个pod）。

• 阶段3：User2加入项目

• 然后，user2（从来没有工作过的项目，加入团队）。 他克隆存储库，然后使用pod install。

• Podfile.lock（应该提交到git repo）的内容将确保他们将获得完全相同的pods，与user1使用完全相同的版本。

即使版本1.2.0的pod C现在可用，user2将获得版本1.0.0中的pod C。 因为这是在Podfile.lock中注册的。 pod C由Podfile.lock（因此是这个文件的名称）锁定到版本1.0.0。

• 阶段4：检查pod的新版本

• 接下来，当user1想要检查是否有可用的pod的更新时。 他们运行pod update，这将告诉他们，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更新，即使只是添加一个新的pod，认为它永远不会存在更新其他pod的风险（因为它们固定在Podfile中）。
• 但实际上，这不足以保证user1和user2在我们上面的场景中将始终获得所有其pod的完全相同的版本。
• 一个典型的例子是如果pod A具有对pod A2的依赖性 - 在A.podspec中声明为依赖“A2”，“〜> 3.0”。 在这种情况下，使用pod'A'，'1.0.0'在您的Podfile将确实强制user1和user2都使用1.0版本的pod A，但是：
• user1可能最终获取到3.4版本的pod A2（因为那是A2的最新版本）
• 而当用户2在稍后加入项目时运行pod安装时，他可能获取到3.5版本的pod A2（因为A2的维护者可能已经同时释放了新版本）。

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