Lockfiles 是什么?

platform :ios, '9.3'

pod 'AFNetworking/Serialization', '~> 3.0'

target 'MyApp'

运行pod安装的开发人员将获得最新的3.x版本，最初可能是3.1版本，但是6个月后，他们可以获得3.4 - 没有锁定文件，没有办法跟踪具体的构建。这就是为什么它应该永远在你的代码库。在上面的情况下，我的lockfile看起来像这样：

PODS:

    - AFNetworking/Serialization (3.1.0)

DEPENDENCIES:

    - AFNetworking/Serialization (~> 3.0)

SPEC CHECKSUMS:

AFNetworking: 5e0e199f73d8626b11e79750991f5d173d1f8b67

PODFILE CHECKSUM: 876ceaa409f4ade2b3d58d310dbe026393824bcc

COCOAPODS: 1.0.0.beta.8

Spec CHECKSUMS能做什么？

通过CocoaPods Master Specs repo，我们尽最大努力确保为公众提供一个一次性的Podspecs存储库。不过，您无法保证每个人都拥有与团队中其他人一样的Podspec版本。

~/D/MyApp ⏛  pod ipc spec ~/.cocoapods/repos/master/Specs/AFNetworking/3.1.0/AFNetworking.podspec.json  | openssl sha1

5e0e199f73d8626b11e79750991f5d173d1f8b67

那为什么我看到流失？

使用git仓库，正常的git开发流程是：

拉取一个分支，更改podfile文件

项目开发

提交到主分支

更新Podspec文件，更新到最新Tag的版本

CocoaPods在后台更新更新仓库做的很十分聪明，但是它并不完美。为了避免重新创建整个Pods文件夹，每次它会检查您的库是否处于预期版本，并跳过重新创建整个过程。

在上面的例子中，我们使用了CocoaPods的Specs repo版本的Podspec。在一个分支中，举例来说:

Podspec在Pods / Local \ Podspecs / AFNetworking.podspec.json中以JSON格式保存到Pods目录中，这是为了确保在Cocodopods沙盒中始终可以访问Podspecs，并且会适当的加快访问速度。这就是podspec用于生成校验和的原因。

那么这怎么会不同步？

•  在开发周期中，使用库时，您将使用pod update [library]来更新正在使用的库。您可以多次使用。

•  PR你在分支上继续做开发，直到你准备要代码审查。此时，你有一个正在开发的版本，你在本地仓库提交了一个PR版用于代码审查。

•  有一些修改影响到podspec的审查，你并没有使用pod update [library]更新仓库，而是回滚了代码（例如，你更改了一些元数据，这不保证另一个更新通过CI 。）

•  一旦所有的代码都审核完，所有的修改都被merge到master分支上

•  运行 pod install - 继续在Pods目录中使用Podspec的旧版本 ，例如：

Pods/Local\ Podspecs/AFNetworking.podspec.json.

•  现在，您的本地Pods文件夹中有较旧的AFNetworking.podspec.json，当下一个人运行pod install并将更改合并时，他们会获得不同的SHA，因为它们具有元数据更改的版本。 

简单修复

最好的选择是在导致流失的计算机上运行pod update [library]，这将告诉CocoaPods专门请求一个新版本的库。如果没有给出与您的团队其余部分相同的校验和，那么有一个很好的老朋友:

rm -rf Pods && pod安装

作者：