pod install 与 pod update的区别

前言

在使用CocoaPods时，难免会混淆pod install 和 pod update的用法，于是在官网找到了相应的说明文章，并决定翻译过来，供大家学习。

以下内容来自:pod install vs. pod update翻译。

CocoaPods

正文

介绍

很多人使用CocoaPods时往往认为pod install只是在首次配置项目的时候使用的，而pod update是稍后更新库的时候使用的。但是事实并非如此。

这篇文章的目的是阐述清楚什么时候使用pod install命令，什么时候使用pod update命令。

综述：

• 使用pod install在你的项目中安装新的库，即使你已经有了Podfile文件并且运行过pod install命令，或者你已经有添加、删除过库。

• 使用pod update [PODNAME]仅仅是在你想更新库版本的时候。

命令的详细细节：

pod install:

该命令是在你第一次在项目中获取库的时候使用，并且在每次你对 Podfile文件编辑的时候（添加、更新、删除）使用。

每一次运行pod install命令后，都会去下载安装新的库，并且会修改Podfile.lock文件中记录的库的版本。Podfile.lock文件是用来追踪和锁定这些库的版本的。

运行pod install后，它仅仅只能解决Podfile.lock中没有列出来的依赖关系。

在Podfile.lock中列出的那些库，也仅仅只是去下载Podfile.lock中指定的版本，并不会去检查最新的版本。

没有在Podfile.lock中列出的那些库，会去检索Podfile中指定的版本，比如pod ‘myPod’, ‘~>1.2’。

pod outdated:

当你使用pod outdated时，CocoaPods会罗列出所有在Podfile.lock中记录的有最新版本的库，意思是，如果你进行了pod update PODNAME操作，只要这些库符合Podfile.lock中的版本限制（如pod MyPod, ‘~>x.y’），那么它就会更新。

pod update

当你运行了 pod update PODNAME命令，CocoaPods将不会考虑Podfile.lock中列出的版本，而直接去查找该库的新版本。它将更新到这个库尽可能新的版本，只要符合Podfile中的版本限制要求。

如果使用pod update 命令不带库名称参数，CocoaPods将会去更新Podfile中每一个库的尽可能新的版本。

正确的用法：

使用pod update PODNAME可以去更新一个库的指定版本（检查相应的库是否存在更新的版本，并且更新）,相对应的，使用pod install将不会更新那些已经下载安装了的库。

当你在Podfile中添加了一个新的库时，你应该使用pod install命令，而不是pod udpate，这样安装了新增的库，也不会重复安装已经存在的库。

使用pod update仅仅只是去更新指定库的版本（或者全部库）。

提交你的Podfile.lock文件:

提醒一下，即使你一向不commit你的库文件到你的共享仓库，你也应该总是commit & push到你的Podfile.lcok文件中。

否则，就会破坏掉pod install 的整个设计逻辑，造成Podfile.lock文件无法锁定你已经安装的库。

场景应用：

这里有一个场景示例来展示在项目的声明周期中各种方案的使用。

例1：用户1创建了一个项目

用户1创建了一个工程，并且想使用A、B、C这三个库，所以他就创建了一个含有这个三个库的Podfile文件，并且运行pod intall命令。

这样就会安装了A、B、C三个库到这个工程里面，假设我们的版本都为1.0.0。

因此Podfile.lock将会跟踪并记录A、B、C这三个库以及它们的版本号1.0.0。

顺便说一下：因为第一次运行pod install，并且Pods.xcodeproj工程文件还不存在，所以这个命令会同时创建Pods.xcodeproj以及.xcworkspace工程文件，这只是这个命令的一个副作用，但不是主要目的。

例2：用户1添加了一个新库

其后，用户1添加了一个库D到Podfile文件中。

然后他就运行pod install命令了。因此即使库B的开发者发布了B的一个新版本1.1.0。但只要是在第一次执行pod install之后发布的新的版本，那么B的版本使用的仍然是1.0.0。因为用户1只是希望添加一个新库D，不希望更新库B。

这就是很多人容易出错的地方，因为他们在这里使用了pod update，而不是pod install，可能是想着“我要更新一下我工程中的库”。

例3：用户2加入到工程中

用户2是一个之前没有参与到这个工程的人，稍后加入到项目中。他使用pod install命令克隆了代码仓库。

如果Podfile.lock被提交到git仓库中，那么Podfile.lock的内容就会确保用户1和用户2会得到完全一样的库。

即使库C已经有了到了1.2.0版本，用户2使用的库C仍然是1.0.0版本，因为库C已经在Podfile.lock里面注册过了，库C的1.0.0版本已经在Podfile.lock中被锁住了。

例4：检查某个库的新版本

之后，用户1想检查pods里面是否有可更新的库时，他执行了 pod outdated，这个命令将会罗列出来：库B有了新版本1.1.0，库C有了新版本1.2.0。

用户1决定更新库B，但不更新库C，所以执行pod update B，这样就把库B从1.0.0更新到1.1.0（同时更新Podfile.lock中相应的库B的版本记录），此时，库C仍然是1.0.0版本，不会被更新到1.2.0。

在Podfile中使用明确的版本还不够

有些人可能认为在Podfile中指定某个库的版本已经足以保证所有项目团队中的人都会使用完全一样的版本，比如：pod 'A', '1.0.0' 。

然后，他们可能认为此时如果添加一个新库的时候，我使用pod update并不会去更新其它的库，因为其它的库已经被限定了固定的版本号。

但事实上，在以上场景中，这不足以保证用户1和用户2用到的库版本完全一样。

一个典型的例子是，如果库A对A2有一个依赖（比如声明在A.podspec中：dependency 'A2', '~> 3.0'），这样的话，在你的Podfile中使用 pod 'A', '1.0.0'将会让用户1和用户2都使用同样版本的库A（1.0.0）。

• 但是，用户1最后可能使用的是版本为3.4的库A2（因为3.4是当时用户1使用的最新版本）。

• 用户2稍后加入到项目中，使用pod install 安装库，得到的库A2版本可能是3.5（假设A2的开发者刚刚发布了A2的新版本3.5）。

这就是为什么使用Podfile.lock这一个方式来保证参与项目的每个开发者的电脑中都使用相同版本的库，并且合理的使用pod install和 pod update。