背景：

在日常开发中，咱们的项目中都会运用到三方库，而且会挑选运用 CocoaPods 进行办理。这其中咱们就会常常遇到关于 podfile.lock 要不要提交，podfile.lock 的作用是干嘛的以及冲突怎样处理，pod install 和 pod update 有什么差异等这些问题，下面就来具体介绍下怎样处理这些问题。

什么是 CocoaPods

CocoaPods是OS X和iOS下的一个第三类库办理工具，经过CocoaPods工具咱们可认为项目添加被称为Pods的依靠库（这些类库有必要是CocoaPods自身所支撑的），而且能够轻松办理其版别。

CocoaPods的优点

1、在引进第三方库时它能够自动为咱们完成各式各样的装备，包含装备编译阶段、连接器选项、甚至是ARC环境下的-fno-objc-arc装备等。

2、运用CocoaPods能够很方便地查找新的第三方库，这些类库是比较“标准的”，而不是网上随便找到的，这样能够让咱们找到真正好用的类库。

关于CocoaPods能够参阅这篇文章：www.jianshu.com/p/9e4e36ba8…

这篇文章主要用来介绍CocoaPods的原理和运用注意事项。

CocoaPods 集成原理

CocoaPods 的原理是将一切的依靠库都放到另一个名为Pods的项目中，可是让主项目依靠Pods项目，
这样，源码办理工作任务从主项目移到了Pods项目中。

1.Pods项目终究会编译成一个名为libPods.a的文件, 主项目只要依靠这个.a文件即可.
2.关于资源文件, CocoaPods提供了一个名为Pods-resources.sh的bash脚本, 该脚本在每次项目
　编译的时分都会履行,将第三方库的各种资源文件复制到目标目录中.
3.CocoaPods经过一个名为Pods.xcconfig的文件在编译设置一切的依靠和参数

libPods.a
Pods-resources.sh
Pods.xcconfig

Cocoapods的下载原理

s.source = { :git => ‘git@10.210.0.140:app/iOS-XXX.git’, :tag => ‘1.0.0’ }

  • 依据:git => ‘git@10.210.0.140:app/iOS-XXX.git’找到对应的git库房；

  • 依据:tag => ‘1.0.0’定位到对应tag的提交(假设没有注明Pod依靠库版别则定位到最后一次的提交)；

  • 在这次提交中检索后缀为.podspec的文件(文件能够随便命名)，验证s.name是否与Podfile中的一致；

  • 假设不一致则install时会报错：[!]Unable to find a specification for ‘React’。验证成功后，就会依据Podspec中的s.source_files找到需求导入的代码文件，并经过其他的的数据找到对应的装备文件或资源文件等；

  • 然后将其下载到本地项目中。

注意：
假设是共有库，这些原理也相同。仅仅共有库要将podspec文件上传到cocoapods。在导入的时分经过名字React去cocoapods匹配对应的podspec，然后依据s.source去找到对应的库房和对应的版别，然后会再去匹配新的podspec，后边的过程就完全相同了。

版别操控原理

当履行完 pod install之后，cocoapods 会生成一个podfile.lock的文件。podfile.lock 文件最大的用途在于多人开发。假设你没有在podfile中指定pods版别pod ‘React’，那么默认为获取当时React依靠库的最新版别。

当团队中的某个人履行完 pod install 指令后，生成的 podfile.lock 文件就记载下了当时最新 pods 依靠库的版别，这时团队中的其他人 check 下来这份包含 podfile.lock 文件的工程今后，再去履行 pod install 指令时，获取下来的 pods 依靠库的版别和最开始用户获取到的版别一致。假设没有podfile.lock文件，后续一切用户履行pod install指令都会获取最新版别的React,这就可能造成一个团队运用的依靠库版别不一致，这对团队协作来说必定是个灾难。在这种情况下，假设团队想运用当时最新版别的React依靠库，有两种方案：

1、更改podfile，使其指向最新版别的‘React’依靠库

2、履行pod update指令；鉴于podfile.lock文件对团队协作如此重要，所以应该参加到版别操控里面。

podfile.lock究竟要不要提交

podfile.lock文件是需求提交的。

当咱们app组件化之后，一个app会包含各种不同的版别组件，而主工程变成一个壳子，用Podfile文件依靠了各种不同的组件，然后咱们的app完成了一次版别迭代上线之后，这个时分需求主工程相对应的组件版别，相对应版别的组件又依靠其他版别组件，假设咱们手动经过spec办理必定十分费事，又假设咱们直接把悉数的组件都写在podfile中，那咱们每次的时分回溯（咱们现在在开发2.0版别，想回到1.0版别）的时分，都需求首先记载之前app版别中对应的悉数组件的版别，然后再在podfile中写上对应的组件版别号，假设组件特别多，需求回溯多次，这样也是十分苦楚的。那有没有最简略一句指令一个履行操作一分钟一步到位回溯之前的版别的方法呢？这个时分咱们就需求依靠podfile.lock文件进行版别办理。

Podfile.lock 中会标示项目当时依靠库的准确版别，其中包含了项目在 Podfile 中直接标示运用的库，以及这些库依靠的其他库。这样的优点是当你跟小伙伴协同开发时，你的小伙伴同步了你的 Podfile.lock 文件后，他履行pod install会装置 Podfile.lock 指定版别的依靠库，这样就能够防止咱们的依靠库不一致而造成问题。因而，CocoaPods 官方强烈推荐把 Podfile.lock 纳入版别操控之下。

所以假设咱们用 Podfile.lock 文件进行版别办理，只需求在主工程（便是那个壳子）中把Podfile.lock 纳入版别操控之下（也便是把主工程对应的 Podfile.lock文件上传到gitlab），而且主工程中的Podfile文件一定不要指定版别号，然后把app 每次封版别的时分在gitlab打上相应的版别号tag，每次咱们想回溯之前版别 只需求切换到当时的tag，然后履行pod install （千万不能履行 pod upodate，因为履行完 pod upodate 对应的 Podfile.lock 里面的库版别会跟着更新）就能够了便是这么简略。

podfile.lock冲突的处理

diff: /../Podfile.lock: No such file or directory
diff: Manifest.lock: No such file or directory
error: The sandbox is not **in** sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.`

平常开发过程中，项目在履行完 pod install 后提示 Podfile.lock 文件被修改，需求提交。可是其他搭档(搭档电脑的pod版别和你的不一致)拉下来代码后，运转项目发现了这个过错，然后履行 pod install ，处理了这个问题，然后再提交了 Podfile.lock 文件。等你再更新代码发现也出现了这个问题，这就会堕入一个死循环。而咱们又不能不提交 Podfile.lock 文件，所以这个问题的处理版别便是将咱们电脑的pod版别号保持一致。

删除旧版别号
sudo gem uninstall -n /usr/local/bin cocoapods -v XXX
装置新版别号的pod
sudo gem install -n /usr/local/bin cocoapods -v XXX

Pod install 和 Pod update的差异

pod install：用于第一次为项目下载pods，还有后续添加或许删除库的时分。
pod update： 用于更新库的版别。会遍历一切的库进行更新，并更新 Podfile.lock 文件。
pod update name: 只会更新指定的库。
pod repo update: 更新整个.cocoapods下的一切库的装备文件,挨个查看对应的框架有没有新版别发布,有的话更新本地的资源装备文件.
pod install --no-repo-update:依据podfile文件或许podfile.lock下载并导入对应的第三方库,越过查看资源装备文件是否需求更新的环节

运用示例

示例1：项目需求依靠A、B、C三个库，当时三个库的版别都是1.0.0，创立 Podfile 文件，履行Pod install。会拉取这三个库，而且Podfile.lock中 A、B、C 的版别都会锁定为1.0.0。

示例2：项目需求添加一个 pod D，在 Podfile 文件中引进D，这里应该运用 pod install。因为仅仅想添加D，而不想更新其他三个库。

示例3：这时假设团队其他成员参加这个项目，克隆了项目库房，然后履行 ‘pod install’。因为Podfile.lock被提交了，所以能确保新成员运用的库版别和我的是相同的。即便 pod A 有’1.1.0’ 版别能够运用，因为 Podfile.lock中锁定的Pod A的版别是1.0.0。

示例4：查看版别更新，假设想更新 pod A到1.1.0版别，而 pod B也有新版别可是不想更新 pod B，这个时分就运用 pod update A 就能够了，这个时分 Podfile.lock 中 pod A的版别信息也会更新。

注意：运用固定版别的 Podfile，例如 pod ‘A’, ‘~> 1.1.0’，这样是不是能够确保项目中的一切成员运用的都是同一个版别？答案是否定的，当在履行 pod update时，只能确保’A’的版别是固定的，可是假设’A’还依靠 pod A1，甲同学拉取的时分A1版别为1.0.0，而当乙同学拉取时 pod A1 最新版别是 ‘1.1.0’ 版别了，就会导致A1的版别为 ‘1.1.0’ 了。这便是为什么确保团队每个成员运用在不同电脑运用同一版别的仅有方式时运用 Podfile.lock 而且适当运用 pod install 和 pod update 。

版别号的逻辑关系

'> 0.1' --- 版别号大于0.1的
‘>= 0.1’ --- 版别0.1和版别号大于0.1的
'< 0.1' --- 版别号小于0.1的
‘<= 0.1' --- 版别号0.1和版别号小于0.1的

版别号的最优匹配

‘~> 0.1.2' --- 版别0.1.2和版别号处于0.1.2-0.2之间的,不包含0.2和更高版别
‘~> 0.1' --- 版别0.1和版别号处于0.1-1.0之间的,不包含1.0和更高版别
‘~> 0' --- 版别0和更高，和没设没啥差异

总结

本文介绍了git提交是podfile.lock要不要提交，podfile.lock 的作用是干嘛的以及冲突怎样处理。pod install 和 pod update 有什么差异。

参阅文章：

www.jianshu.com/p/52c5035c9…

www.jianshu.com/p/2dc97f9a6…