pod install vs pod update

1.pod install

1.1.使用场景

• 我们在项目中第一次使用 CocoaPods，进行安装的时候会使用这个命令；
• 我们在 Podfile 中增加或删除某个 pod 后，也是使用这个命令，而不是使用 pod update。

1.2.执行流程

每次运行 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.1’）。

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

2.pod update

• 当运行 pod update PODNAME 时， CocoaPods 将尝试查找 PODNAME 更新的 pod 版本，会忽略掉 Podfile.lock 中已经存在的版本；
• 如果直接运行 pod update ，没有指定 PODNAME,，CocoaPods 会把 Podfile 中所有的 pod 都更新到最新版本（如果已经是最新版本了，则不更新）。

3.pod outdated

当运行 pod outdated 时， CocoaPods 将列出所有比 Podfile.lock（每个 pod 当前安装的版本）中，已经列出的版本更新的 pod 版本。这意味着如果你在这些 pod 上运行 pod update PODNAME， 它将会把指定的 pod 更新到最新版本。

4.Podfile.lock

有时候可能你不想提交 Pods 目录到源代码管理中，但是在多人开发的情况下，一定要提交 Podfile.lock 这个文件，因为这个文件里面记录了你的 Podfile 中所有 pod 的版本信息，为避免你的 Podfile 中的 pod 版本和别人的 Podfile 中的 pod 发生版本不一样的情况，而导致出现函数找不到或者其他的错误。

5.用途及场景实例

5.1.用途

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

当向 Podfile 中添加一个 pod 时，应该运行 pod install，而不是用 pod update 来安装这个新 pod。只有在想要更新特定 pod（或所有的pod）的版本时才会使用 pod update。

5.2.场景实例

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 中记录的 pod C就是 1.0.0 版本。

4. 检查pod的新版本

   假如user1想要检查下是否有更新pod的版本，运行 pod outdated，会告诉你 podB有一个新 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)。

6.使用指定版本的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 的原因。

7.能否将Pods目录添加到源代码管理中？

是否将 Pods 文件夹添加到源代码管理中都取决于您自己，因为工作流程因项目而异。一般建议将Pods目录保留在源代码管理下，不要将其添加到您的.gitignore，但最终这个决定取决于你。需要注意的是，无论您是否在忽略 Pods 目录，Podfile && Podfile.lock 都应始终在版本控制下管理。

7.1.添加Pod目录的好处

• 克隆了 repo 后，即使没有在机器上安装 CocoaPods，项目也可以立即构建和运行，无需运行 pod install，也无需网络连接；
• Pod（代码/库）总是可用的，即使Pod的源（例如GitHub）要关闭也是如此；
• 在克隆 repo 后，Pod 组件保证与原始安装中的组件相同。

7.2.忽略Pods目录的好处

• 源代码仓库将更小，并且占用更少的空间；
• 只要所有 Pod 的源（例如GitHub）都可用，CocoaPods 通常能够重新创建相同的安装；
• 执行源控制操作时不会有任何冲突，例如合并具有不同Pod版本的分支。

参考地址：

正确的使用pod install 和 pod update - CocoaPods
Using CocoaPods
pod install vs. pod update