pod是否纳入版本控制完全取决于你的项目，但是我建议将pod目录纳入版本控制，但是最终决定权还是在你手中。
检查Pods目录的好处
- 克隆后，项目可以立即运行，即使没有在机器上安装CocoaPods。 且没有必要运行pod install，同时不需要Internet连接。
- Pod工件（代码/库）总是可用的，即使Pod的源（例如GitHub）下架。
- 克隆仓库后，Pod文件保证与原始安装中的相同。
忽略Pods目录的好处
- 源代码控制仓库将更小，占用更少的空间。
- 只要所有Pod的源（例如GitHub）可用，CocoaPods通常能够重新创建相同的安装。 （技术上，不能保证在不使用Podfile中的提交SHA时，运行pod install将获取和重新创建相同的文件，这在Podfile中使用zip文件时尤其如此）。
- 执行源代码控制操作时不会有任何冲突，例如合并不同Pod版本的分支。
什么是Podfile.lock？
此文件在第一次运行pod安装后生成，并跟踪安装的每个Pod的版本。 例如，假设在Podfile中指定的以下依赖关系：
pod 'RestKit'
运行pod安装将安装当前版本的RestKit，同时生成Podfile.lock，标识安装的精确版本（例如RestKit 0.10.3）。 多亏了Podfile.lock，在不同的机器上运行pod安装在例子中的项目上，以后在一个不同的机器上仍然会安装RestKit 0.10.3，即使一个较新的版本可用。 CocoaPods将在Podfile.lock中的Pod版本，除非在Podfile或pod更新被调用（这将导致生成一个新的Podfile.lock）中进行相关更新。 这样CocoaPods避免了由意外更改依赖关系导致的头痛。
内部原理
在Xcode中，直接从ruby源引用它：
1.创建或更新workspace。
2.如果需要，将项目添加到工作区。
3.如果需要的话添加CocoaPods static library project到workspace。
4.添加libPods.a到targets => build phases => link with libraries.
5.将CocoaPods Xcode配置文件添加到应用程序的项目中。
6.将应用的目标配置更改为基于CocoaPods的。
7.Adds a build phase to copy resources from any pods you installed to your app bundle. i.e. a ‘Script build phase’ after all other build phases with the following:
- Shell: /bin/sh
- Script: ${SRCROOT}/Pods/PodsResources.sh
注意，如果CocoaPods静态库已经在您的项目中，则跳过前三个步骤。 这主要是由于于Jonah Williams是基于静态库工作的。
