pod 'xxx', :git => '本地代码仓库的路径', :tag => '2.2.2' :#后方可以跟:tag参数来指定相关的tag号。当然后边还可以通过:branch => '分支号'来指定依赖于某个分支，通过:commit => 'commit号'来指定那个提交。
2、Pod Install配置完Podfile文件，接下来就是该在相关的工程中安装相关的依赖了。下方使用了pod install来安装相关的依赖，使用pod update来更新相关的依赖。在安装依赖时会提示安装了哪些依赖的库。因为CocoaPods在安装后会修改我们的Xcode工程，生成一个工作空间，这个工作空间由我们的Project工程和Pods工程组成，我们所依赖的仓库就位于这个Pods工程中，所以安装完毕后提示要通过xxxx.xcworkspace文件来打开整个工程。pod install完毕后，我们会发现整个工程中多了一些文件，比如xxxx.xcworkspace、Pods、Podfile.lock等。我们就通xxxx.xcworkspace来打开相关文件，其他文件稍后会介绍到。
下方就是我们通过open CocoaPodsTestProject.xcworkspace打开的相关工程。下方的Pods中就包括相关依赖的仓库。我们就可以在我们的工程中直接引入使用所依赖的仓库了。上面也提到了，安装后会生成一个工作空间workspace。该workspace就由我们原有的工程和新增的Pods工程组成。通过CocoaPods管理的依赖库都会放在这个Pods工程中。具体如下所示：
3、锁版文件 podfile.lock
上面简单的提了一下podfile.lock文件。咋安装之前我们创建了一个叫做 podfile 的依赖相关的描述文件。在pod install后会生成一个叫做podfile.lock的文件。下方截图中是该文件中的相关内容。其中记录了目前依赖的一些仓库以及一些版本，该文件的目的就是锁定依赖仓库版本的。该 podfile.lock 本质上是用来锁版本的，为了避免版本不一致的情况发生。
我们来看一下如果没有Podfile.lock文件，会发生什么情况。当在 podfile 中添加了相关依赖仓库，但是没有添加相关的依赖仓库的版本，那么在每次 pod insall 时都会安装该仓库最新的版本。当一个工程有多个人开发时，A同学 在 B同学 之前进行的pod install, 而在A同学安装后一些仓库进行了更新，那么在 B同学 安装仓库时就会寻找这个最新的版本。那么这种情况下就会出现同一个工程中所依赖的仓库版本不一致的问题。为了解决这个版本不一致的问题，于是乎就引入了Podfile.lock这个所版本用的文件。当然在框架中的包管理器中也是存在类似的lock文件的，比如 node.js 中的npm包管理器。
引入 podfile.lock 文件后，上面的版本不一致的问题就很好的解决了。在首次 pod install 后，会生成一个 podfile.lock 文件，该文件中会记录此次 install 所安装的版本。当再次进行 pod install时，对那些没有指定版本的依赖仓库会使用podfile.lock 文件中记录的版本。如果在 podfile 中指定了相关版本，那么就直接引用 podfile 中指定的版本然后在更新 podfile.lock中记录的版本即可。
接下来我们通过具体示例来看一下该podfile.lock文件的作用。我们将podfile中的AFNetworking的版本号给删掉，然后再次进行pod install。此刻并不会安装最新的AF版本，因为在podfile.lock中已经记录下了当前使用的AF版本了，所以再次进行 pod install 时仍然会加载 podfile.lock中记录的版本。
当然你可以使用pod update命令来进行更新，使podfile.lock中记录的版本进行更新。当然也可以在podfile文件中指定相关依赖仓库的版本，然后再执行pod install来更新相关的版本。具体如下所示 ：