cocospod 安装和使用

一 ruby 安装

  要安装coocspod 首先需要安装ruby,可以先安装xcode,在安装macport 下载地址,最后执行命令 port install ruby

二、安装CocoaPods

1、安装

CocoaPods是用Ruby实现的，要想使用它首先需要有Ruby的环境。幸运的是OS X系统默认的已经可以运行Ruby了，因此我们只需要执行以下命令：

[objc]  view plain copy

1. $ sudo gem install cocoapods  

CocoaPods是以Ruby gem包的形式被安装的。在安装执行的过程中，可能会问我们是不是更新rake，输入y即可。这是因为rake gem包会在安装的过程中检查更细，如果有可用的新版本就会出现刚才的选项。

在安装进程结束的时候，执行命令：

[objc]  view plain copy

1. $ pod setup  

如果没有报错，就说明一切安装就成功了！

2、安装过程中可能遇到的问题

①执行完install命令半天没反应

这有可能是因为Ruby的默认源使用的是cocoapods.org，国内访问这个网址有时候会有问题，网上的一种解决方案是将远替换成淘宝的，替换方式如下：

[objc]  view plain copy

1. $ gem sources --remove https://rubygems.org/  
2. //等有反应之后再敲入以下命令  
3. $ gem sources -a http://ruby.taobao.org/  

要想验证是否替换成功了，可以执行：

[objc]  view plain copy

1. $ gem sources -l  

正常的输出是：

[objc]  view plain copy

1. *** CURRENT SOURCES ***  
2.   
3. http://ruby.taobao.org/  

②gem版本过老

gem是管理Ruby库和程序的标准包，如果它的版本过低也可能导致安装失败，解决方案自然是升级gem，执行下述命令即可：

[objc]  view plain copy

1. $ sudo gem update --system  

③安装完成后，执行pod setup命令时报错：

[objc]  view plain copy

1. /Users/wangzz/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:298:in `to_specs': Could not find 'cocoapods' (>= 0) among 6 total gem(s) (Gem::LoadError)  
2.     from /Users/wangzz/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:309:in `to_spec'  
3.     from /Users/wangzz/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_gem.rb:53:in `gem'  
4.     from /Users/wangzz/.rvm/rubies/ruby-1.9.3-p448/bin/pod:22:in `<main>'  

这就是路径设置的问题，可以通过执行：

[objc]  view plain copy

1. $ rvm use ruby-1.9.3-p448  

解决该问题。

3、升级CocoaPods

升级很简单，再次执行安装命令即可：

[objc]  view plain copy

1. $ sudo gem install cocoapods  

需要注意的是，如果安装的时候使用了sudo，升级的时候一样需要使用该关键字，不然升级完了以后又会出现路径不匹配问题。

三、使用CocoaPods

如果之前做的一切顺利，接下来就可以体验体验CocoaPods的神奇之处了，需要经过以下几步：

为了演示这个过程，我创建了一个名为CocoaPodsTest的工程。

1、创建Podfile

CocoaPods的一切都是从一个名为Podfile的文件开始的，我们需要先创建这个文件。个人习惯使用命令行，我会这样做：

[objc]  view plain copy

1. $ cd /Users/wangzz/Desktop/CocoaPodsTest  
2. $ touch Podfile  

首先进入到工程的根目录下，创建空白的Podfile文件，创建完毕的目录结构如下图：

PS：Podfile文件也可以不放在工程的根目录下，只是会稍微麻烦点，在下一篇文章中会有介绍，敬请关注。）

2、编辑Podfile

根据需要，我们可以在Podfile文件中写入需要用到的第三方库，以SBJson、AFNetworking、Reachability三个库为例，我的Podfile内容如下：

[objc]  view plain copy

1. platform :ios  
2. pod 'Reachability',  '~> 3.0.0'  
3. pod 'SBJson', '~> 4.0.0'  
4.   
5. platform :ios, '7.0'  
6. pod 'AFNetworking', '~> 2.0'  

3、执行导入命令

准备工作都完成后，开始导入第三方库：

[objc]  view plain copy

1. $ cd /Users/wangzz/Desktop/CocoaPodsTest  
2. $ pod install  

首先进入工程根目录，然后执行pod install命令，CocoaPods就开始为我们做下载源码、配置依赖关系、引入需要的framework等一些列工作，命令的执行结果打印出来如下：

[objc]  view plain copy

1. Analyzing dependencies  
2. Downloading dependencies  
3. Installing AFNetworking (2.1.0)  
4. Installing JSONKit (1.5pre)  
5. Installing Reachability (3.0.0)  
6. Generating Pods project  
7. Integrating client project  
8.   
9. [!] From now on use `CocoaPodsTest.xcworkspace`.  

这就说明pod install命令执行成功了。再来看看工程根目录发生的变化，如下图：

 可以看到，工程的根目录下多了三个东西：CocoaPodsTest.xcworkspace、Podfile.lock文件和Pods目录。

（PS：篇幅有限，Podfile.lock文件会放到系列文章的下一篇介绍，敬请关注。）

再看看刚才执行完pod install命令打印出来的内容的最后一行：

[objc]  view plain copy

1. [!] From now on use `CocoaPodsTest.xcworkspace`.  

提示我们从现在起，我们需要使用 CocoaPodsTest.xcworkspace文件来开发。

对于工程发生的变化，有几点需要说明：

• 第三方库会被编译成静态库供我们正真的工程使用

CocoaPods会将所有的第三方库以target的方式组成一个名为Pods的工程，该工程就放在刚才新生成的Pods目录下。整个第三方库工程会生成一个名称为libPods.a的静态库提供给我们自己的CocoaPodsTest工程使用。

• 我们的工程和第三方库所在的工程会由一个新生成的workspace管理

为了方便我们直观的管理工程和第三方库，CocoaPodsTest工程和Pods工程会被以workspace的形式组织和管理，也就是我们刚才看到的CocoaPodsTest.xcworkspace文件。

原来的工程设置已经被更改了，这时候我们直接打开原来的工程文件去编译就会报错，只能使用新生成的workspace来进行项目管理。

打开CocoaPodsTest.xcworkspace，界面如下：

四、Podfile.lock文件

上文讲过，在开始使用CocoaPods，执行完pod install之后，会生成一个Podfile.lock文件。这个文件看起来跟我们关系不大，实际上绝对不应该忽略它。

该文件用于保存已经安装的Pods依赖库的版本，通过CocoaPods安装了SBJson、AFNetworking、Reachability三个POds依赖库以后对应的Podfile.lock文件内容为：

[objc]  view plain copy

1. PODS:  
2.   - AFNetworking (2.1.0):  
3.     - AFNetworking/NSURLConnection  
4.     - AFNetworking/NSURLSession  
5.     - AFNetworking/Reachability  
6.     - AFNetworking/Security  
7.     - AFNetworking/Serialization  
8.     - AFNetworking/UIKit  
9.   - AFNetworking/NSURLConnection (2.1.0):  
10.     - AFNetworking/Reachability  
11.     - AFNetworking/Security  
12.     - AFNetworking/Serialization  
13.   - AFNetworking/NSURLSession (2.1.0):  
14.     - AFNetworking/NSURLConnection  
15.   - AFNetworking/Reachability (2.1.0)  
16.   - AFNetworking/Security (2.1.0)  
17.   - AFNetworking/Serialization (2.1.0)  
18.   - AFNetworking/UIKit (2.1.0):  
19.     - AFNetworking/NSURLConnection  
20.   - Reachability (3.0.0)  
21.   - SBJson (4.0.0)  
22.   
23. DEPENDENCIES:  
24.   - AFNetworking (~> 2.0)  
25.   - Reachability (~> 3.0.0)  
26.   - SBJson (~> 4.0.0)  
27.   
28. SPEC CHECKSUMS:  
29.   AFNetworking: c7d7901a83f631414c7eda1737261f696101a5cd  
30.   Reachability: 500bd76bf6cd8ff2c6fb715fc5f44ef6e4c024f2  
31.   SBJson: f3c686806e8e36ab89e020189ac582ba26ec4220  
32.   
33. COCOAPODS: 0.29.0  

Podfile.lock文件最大得用处在于多人开发。对于没有在Podfile中指定Pods依赖库版本的写法，如下：

[objc]  view plain copy

1. pod 'SBJson'  

该句话用于获取当前SBJson这个Pods依赖库的最新版本。
当团队中的某个人执行完pod install命令后，生成的Podfile.lock文件就记录下了当时最新Pods依赖库的版本，这时团队中的其它人check下来这份包含Podfile.lock文件的工程以后，再去执行pod install命令时，获取下来的Pods依赖库的版本就和最开始用户获取到的版本一致。如果没有Podfile.lock文件，后续所有用户执行pod install命令都会获取最新版本的SBJson，这就有可能造成同一个团队使用的依赖库版本不一致， 这对团队协作来说绝对是个灾难！

在这种情况下，如果团队想使用当前最新版本的SBJson依赖库，有两种方案：

• 更改Podfile，使其指向最新版本的SBJson依赖库；
• 执行pod update命令；

鉴于Podfile.lock文件对团队协作如此重要，我们需要将它添加到版本管理中。

五、Podfile文件

对于普通用户来说，使用CocoaPods我们打交道最多的就是Podfile文件。CocoaPods是用ruby实现的，因此Podfile文件的语法就是ruby的语法。接着从以下几个方面来介绍Podfile:

1、Podfile文件存放位置

这是在上篇文章中，遗留的一个问题。通常情况下我们都推荐Podfile文件都放在工程根目录，如下图所示：

 事实上Podfile文件可以放在任意一个目录下，需要做的是在Podfile中指定工程的路径，和原来相比，Podfile文件就在最开始的位置增加了一行，具体内容如下：

[objc]  view plain copy

1. xcodeproj "/Users/wangzz/Desktop/CocoaPodsTest/CocoaPodsTest.xcodeproj"  
2.   
3. platform :ios    
4. pod 'Reachability',  '~> 3.0.0'    
5. pod 'SBJson', '~> 4.0.0'    
6.     
7. platform :ios, '7.0'    
8. pod 'AFNetworking', '~> 2.0'   

指定路径使用的是xcodeproj关键字。

此后，进入Podfile文件所在路径，执行pod install命令就会和之前一样下载这些Pods依赖库，而且 生成的相关文件都放在了Podfile所在目录下面，如下图：

 和之前一样，我们仍然需要使用这里生成的workspace文件打开工程。

2、Podfile和target

Podfile本质上是用来描述Xcode工程中的targets用的。如果我们不显式指定Podfile对应的target，CocoaPods会创建一个名称为default的隐式target，会和我们工程中的第一个target相对应。换句话说， 如果在Podfile中没有指定target，那么只有工程里的第一个target能够使用Podfile中描述的Pods依赖库。

如果想在一个Podfile中同时描述project中的多个target，根据需求的不同，可以有不同的实现方式。为了说明问题，在原来的工程中再创建一个名称为Second的target，现在的project中包含的target有

 ①多个target中使用相同的Pods依赖库

比如，名称为CocoaPodsTest的target和Second的target都需要使用Reachability、SBJson、AFNetworking三个Pods依赖库，可以使用 link_with关键字来实现，将Podfile写成如下方式：

[objc]  view plain copy

1. link_with 'CocoaPodsTest', 'Second'  
2. platform :ios    
3. pod 'Reachability',  '~> 3.0.0'    
4. pod 'SBJson', '~> 4.0.0'    
5.     
6. platform :ios, '7.0'    
7. pod 'AFNetworking', '~> 2.0'   

这种写法就实现了CocoaPodsTest和Second两个target共用相同的Pods依赖库。

②不同的target使用完全不同的Pods依赖库

CocoaPodsTest这个target使用的是Reachability、SBJson、AFNetworking三个依赖库，但Second这个target只需要使用OpenUDID这一个依赖库，这时可以使用 target关键字，Podfile的描述方式如下：

[objc]  view plain copy

1. target :'CocoaPodsTest' do  
2. platform :ios    
3. pod 'Reachability',  '~> 3.0.0'    
4. pod 'SBJson', '~> 4.0.0'    
5.     
6. platform :ios, '7.0'    
7. pod 'AFNetworking', '~> 2.0'  
8. end  
9.   
10. target :'Second' do  
11. pod 'OpenUDID', '~> 1.0.0'  
12. end  

其中，do/end作为开始和结束标识符。

3、使用Podfile管理Pods依赖库版本

再引入依赖库时，需要显示或隐式注明引用的依赖库版本，具体写法和表示含义如下：

[objc]  view plain copy

1. pod 'AFNetworking'      //不显式指定依赖库版本，表示每次都获取最新版本  
2. pod 'AFNetworking', '2.0'     //只使用2.0版本  
3. pod 'AFNetworking', '> 2.0'     //使用高于2.0的版本  
4. pod 'AFNetworking', '>= 2.0'     //使用大于或等于2.0的版本  
5. pod 'AFNetworking', '< 2.0'     //使用小于2.0的版本  
6. pod 'AFNetworking', '<= 2.0'     //使用小于或等于2.0的版本  
7. pod 'AFNetworking', '~> 0.1.2'     //使用大于等于0.1.2但小于0.2的版本  
8. pod 'AFNetworking', '~>0.1'     //使用大于等于0.1但小于1.0的版本  
9. pod 'AFNetworking', '~>0'     //高于0的版本，写这个限制和什么都不写是一个效果，都表示使用最新版本  

六、CocoaPods常用命令

1、pod install

根据Podfile文件指定的内容，安装依赖库，如果有Podfile.lock文件而且对应的Podfile文件未被修改，则会根据Podfile.lock文件指定的版本安装。

每次更新了Podfile文件时，都需要重新执行该命令，以便重新安装Pods依赖库。

2、pod update

若果Podfile中指定的依赖库版本不是写死的，当对应的依赖库有了更新，无论有没有Podfile.lock文件都会去获取Podfile文件描述的允许获取到的最新依赖库版本。

3、pod search

命令格式为：

[objc]  view plain copy

1. $ pod search OpenUDID  

后面的OpenUDID为参数。

从命令的名称不难看出，该命令是用来按名称搜索可用的Pods依赖库，执行结果如下：

[objc]  view plain copy

1. -> OpenUDID (1.0.0)  
2.    Open source initiative for a universal and persistent UDID solution for iOS.  
3.    pod 'OpenUDID', '~> 1.0.0'  
4.    - Homepage: http://OpenUDID.org  
5.    - Source:   https://github.com/ylechelle/OpenUDID.git  
6.    - Versions: 1.0.0 [master repo]  

这里我们搜到了一条可用数据，里面描述了OpenUDID库的简要信息。其实我们真正需要的是上述结果中的第三行：

[objc]  view plain copy

1. pod 'OpenUDID', '~> 1.0.0'  

不难看出，这是我们需要添加到Podfile文件中的。

有了这条命令，就可以方便、迅速地找到需要的Pods依赖库。

4、pod setup

命令格式为：

[ruby]  view plain copy

1. $ pod setup  

执行完了以后会打印：

[ruby]  view plain copy

1. Setting up CocoaPods master repo  
2. Updating 7cd4668..f3d3ced  
3.   
4. Fast-forward  

接下来还会打印很多更新信息。

这条命令用于跟新本地电脑上的保存的Pods依赖库tree。由于每天有很多人会创建或者更新Pods依赖库，这条命令执行的时候会相当慢，还请耐心等待。我们需要经常执行这条命令，否则有新的Pods依赖库的时候执行pod search命令是搜不出来的。

七、创建自己的github仓库

CocoaPods都托管在github上(官方链接为：https://github.com/CocoaPods)，所有的Pods依赖库也都依赖github，因此第一步我们需要创建一个属于自己的github仓库。仓库创建界面如下图：

 上图中标了序号的共6处，对应的说明如下：

1、Repository name

仓库名称，这里写成WZMarqueeView，必填的；

2、Description

仓库的描述信息，可选的；

3、仓库的公开性

这里只能选Public，一个是因为Private是要money的，再一个Private别人看不到还共享个毛；

4、是否创建一个默认的README文件

一个完整地仓库，都需要README说明文档，建议选上。当然不嫌麻烦的话你也可以后面再手动创建一个；

5、是否添加.gitignore文件

.gitignore文件里面记录了若干中文件类型，凡是该文件包含的文件类型，git都不会将其纳入到版本管理中。是否选择看个人需要；

6、license类型

正规的仓库都应该有一个license文件，Pods依赖库对这个文件的要求更严，是必须要有的。因此最好在这里让github创建一个，也可以自己后续再创建。我使用的license类型是MIT。

上面的各项都填写完毕后，点击Create repository按钮即可，创建成功地界面如图

 到这，仓库创建过程就结束了。

二、clone仓库到本地

为了便于向仓库中删减内容，需要先将仓库clone到本地，操作方式有多种，推荐使用命令行：

[objc]  view plain copy

1. $ git clone https://github.com/wangzz/WZMarqueeView.git  

操作完成后，github上对应的文件都会拷贝到本地，目录结构为：

 github上仓库中的.gitignore文件是以.开头的隐藏文件，因此这里只能看到两个。

后续我们的所有文件增、删、改都在这个目录下进行。

八、向本地git仓库中添加创建Pods依赖库所需文件

注意： 以下描述的文件都要放在步骤二clone到本地的git仓库的根目录下面。

1、后缀为.podspec文件

该文件为Pods依赖库的描述文件，每个Pods依赖库必须有且仅有那么一个描述文件。文件名称要和我们想创建的依赖库名称保持一致，我的WZMarqueeView依赖库对应的文件名为WZMarqueeView.podspec。

1.1 podspec文件内容

WZMarqueeView.podspec的保存内容为

[ruby]  view plain copy

1. Pod::Spec.new do |s|  
2.   s.name             = "WZMarqueeView"  
3.   s.version          = "1.0.0"  
4.   s.summary          = "A marquee view used on iOS."  
5.   s.description      = <<-DESC  
6.                        It is a marquee view used on iOS, which implement by Objective-C.  
7.                        DESC  
8.   s.homepage         = "https://github.com/wangzz/WZMarqueeView"  
9.   # s.screenshots      = "www.example.com/screenshots_1", "www.example.com/screenshots_2"  
10.   s.license          = 'MIT'  
11.   s.author           = { "王中周" => "wzzvictory_tjsd@163.com" }  
12.   s.source           = { :git => "https://github.com/wangzz/WZMarqueeView.git", :tag => s.version.to_s }  
13.   # s.social_media_url = 'https://twitter.com/NAME'  
14.   
15.   s.platform     = :ios, '4.3'  
16.   # s.ios.deployment_target = '5.0'  
17.   # s.osx.deployment_target = '10.7'  
18.   s.requires_arc = true  
19.   
20.   s.source_files = 'WZMarqueeView/*'  
21.   # s.resources = 'Assets'  
22.   
23.   # s.ios.exclude_files = 'Classes/osx'  
24.   # s.osx.exclude_files = 'Classes/ios'  
25.   # s.public_header_files = 'Classes/**/*.h'  
26.   s.frameworks = 'Foundation', 'CoreGraphics', 'UIKit'  
27.   
28. end  

该文件是ruby文件，里面的条目都很容易知道含义。

其中需要说明的又几个参数：

①s.license

Pods依赖库使用的license类型，大家填上自己对应的选择即可。

②s.source_files

表示源文件的路径， 注意这个路径是相对podspec文件而言的。

③s.frameworks

需要用到的frameworks， 不需要加.frameworks后缀。

 1.2 如何创建podspec文件

大家创建自己的podspec文件可以有两个途径：

①copy我的podspec文件然后修改对应的参数，推荐使用这种方式。

②执行以下创建命令：

[ruby]  view plain copy

1. $ pod spec create WZMarqueeView  

也会创建名为WZMarqueeView.podspec的文件。但是打开创建完的文件你就会发现里面的东西太多了，很多都是我们不需要的。

2、LICENSE文件

CocoaPods强制要求所有的Pods依赖库都必须有license文件，否则验证不会通过。license的类型有很多种，详情可以参考网站 tl;dr Legal。在创建github仓库的时候，我已经选择了MIT类型的license。

3、主类文件

创建Pods依赖库就是为了方便别人使用我们的成果，比如我想共享给大家的WZMarqueeView类，是我想提供给广大用户使用的，这个类自然是必不可少的。我把这个类包含的两个文件放到一个名称为WZMarqueeView的文件夹中，对应的目录结构如图：

里面包含两个文件：WZMarqueeView.h和WZMarqueeView.m

4、demo工程

为了快速地教会别人使用我们的Pods依赖库，通常需要提供一个demo工程。我创建的demo工程放到了一个名为WZMarqueeViewDemo的文件夹中，该目录包含的文件如下图所示：

5、README.md

使用github的人应该都熟悉这个文件，它是一个成功github仓库必不可少的一部分，使用的是markdown标记语言，用于对仓库的详细说明。

以上所说的5个是创建Pods依赖库所需最基础的文件， 其中1、2、3是必需的，4、5是可选但强烈推荐创建的。

添加完这些文件以后，我的github本地仓库目录就变成了下图所示的样子：

九、提交修改文件到github

经过步骤三，向本地的git仓库中添加了不少文件，现在需要将它们提交到github仓库中去。提交过程分以下几步：

1、pod验证

执行以下命令：

[ruby]  view plain copy

1. $ set the new version to 1.0.0  
2. $ set the new tag to 1.0.0  

这两条命令是为pod添加版本号并打上tag。然后执行pod验证命令：

[ruby]  view plain copy

1. $ pod lib lint  

如果一切正常，这条命令执行完后会出现下面的输出：

[ruby]  view plain copy

1. -> WZMarqueeView (1.0.0)  
2.   
3. ZMarqueeView passed validation.  

到此，pod验证就结束了。

需要说明的是，在执行pod验证命令的时候，打印出了任何warning或者error信息，验证都会失败！如果验证出现异常，打印的信息会很详细，大家可以根据对应提示做出修改。

2、本地git仓库修改内容上传到github仓库

依次执行以下命令：

[ruby]  view plain copy

1. $ git add -A && git commit -m "Release 1.0.0."  
2. $ git tag '1.0.0'  
3. $ git push --tags  
4. $ git push origin master  

上述命令均属git的范畴，这里不多述。如果一切正常，github上就应该能看到自己刚添加的内容了。如下图所示：

十、上传podspec文件到CocoaPods官方仓库中

经过前边的四步操作，你可能以为已经结束了，不幸的是还早着呢。

要想一个Pods依赖库真正可用，还需要做最后一步操作，将我们刚才生成的podspec文件上传到CocoaPods官方的Specs仓库中，链接为：https://github.com/CocoaPods/Specs

打开这个链接你就会发现，原来我们能使用的，以及我们使用pod search命令能搜索到的所有Pods依赖库都会把它们的podspec文件上传到这个仓库中，也就是说，只有将我们的podspec文件上传到这个仓库中以后，才能成为一个真正的Pods依赖库，别人才能正常使用！

按照git的规则，要想向别人的仓库中添加文件，必须先fork一份别人的仓库，做完相应地修改后，在push给仓库的原作者，等到作者审核通过，然后合并到原来的仓库中。

流程明白了以后，自然知道该怎么干了：

1、fork一份CocoaPods官方的Specs仓库

进入到刚才的官方仓库链接中，点击屏幕右上角的fork按钮，如下图：

然后大家会发现自己名下会多一份仓库的分支。比如我的分支为：

2、将fork的仓库clone到本地

执行以下命令：

[ruby]  view plain copy

1. $ git clone https://github.com/wangzz/Specs.git  

注意， 大家需要将对应的仓库地址换成自己的。

这个仓库有点大，需要有耐心啊。

3、将自己的podspec文件添加到本地Specs仓库中

Specs仓库clone到本地后，会放到一个名为Specs的文件夹中。podspec文件在Specs仓库中的保存原则是：

Pods依赖库同名文件夹--->版本号同名文件夹--->podspec文件

照此原则，我需要在Specs文件夹下建立一个名为WZMarqueeView的文件夹，然后进入到WZMarqueeView文件夹下，建立一个名称为1.0.0的文件夹，最后进入到1.0.0这个文件夹下，并且将之前创建好的WZMarqueeView.podspec文件拷贝进来。

不难理解，如果以后有对WZMarqueeView类的升级，就在WZMarqueeView文件夹下建立对应版本名称的文件夹，用于保存对应版本的podspec文件即可。

这些操作完成后，目录层次结构如下所示：

4、上传本地Specs仓库中的修改到github仓库

执行以下命令：

[ruby]  view plain copy

1. $ git add -A && git commit -m "Add WZMarqueeView podspec file"  
2. $ git push origin master  

成功以后就能在github上自己fork的Specs仓库中看到刚上传的文件了。

5、将在自己fork的Specs上做的修改pull给CocoaPods官方的Specs仓库

进入到自己fork的Specs仓库中，会看到屏幕左上角有一个绿色按钮

该按钮点进去以后会有如下图所示的界面：

点击图中的绿色Create Pull Request按钮，即可将我们fork的Specs上做的修改pull给CocoaPods官方的Specs仓库。

到这一步后，剩下的工作就只有等了，等待CocoaPods的维护人员审核并将我们pull上去的修改合并到官方的Specs仓库中，这个过程通常会有一天左右的等待时间。如果有任何消息，比如审核不通过，或者审核通过了，CocoaPods官方都会发邮件通知的。

等到审核通过的时候，我们就能在官方的Specs仓库中看到自己上传的文件夹了。

6、查看审核进度

当然我们也能查看审核进度，打开这个链接： https://github.com/CocoaPods/Specs/pulls，这里能看到所有的Specs仓库pull请求，如下图：

红圈标识的就是我刚才pull上来的请求，点进去以后就能看到对应的审核进度。

十一、查看我们自己创建的Pods依赖库

如果收到了CocoaPods官方发过来的审核通过邮件以后，你可能很着急的想在自己的电脑上执行pod search命令，看看能不能搜索到自己创建的Pods依赖库。不过你肯定会失望的，因为还需要执行一条命令才能在我们的本地电脑上使用search命令搜索到我们的依赖库：

[ruby]  view plain copy

1. $ pod setup  

在我的CocoaPods系列教程中的第一篇： CocoaPods详解之----进阶篇中的最后部分介绍过这条命令，它会将所有的Pods依赖库tree跟新到本地。执行完这条命令，再去执行:

[ruby]  view plain copy

1. $ pod search WZMarqueeView  

就能显示出对应的介绍信息了！