今天没想好写点什么，在重新读《区块链，从数字货币到信用社会》这本书，这本书对我认识区块链有很大的启发。

今天在细读的一篇文章，也是上面这本书的一篇序文《区块链，建设互联网的价值高速公路》。里面有一段话：

今年的区块链资产的目标是一千万，意味着自己手里的币资产要翻五倍才能达到，在传统行业要翻五倍简直不可想象，但是在区块链领域，更神奇的事情都能发生，导致我真的坚信年底能到1000万，我说万一，真的万一实现不了，朋友们一定给我筹够1000万，明年我们搞个小目标一个亿。

为了给自己壮壮胆，打打气，我找下历史上在币市要实现1000万这个目标要怎么做。

今天6月8号，吉利日子开工搞事的结果肯定不会太差。今天对我很重要，我用这篇日记宣告自己要all in区块链搞事情了。至于今天对其他朋友是否重要，就看我能把事情搞多大，让多少朋友收益了。熟悉我的朋友应该已经知道我去年开始炒币挖矿赚了钱，不少朋友被我带进坑，有些朋友赚的盆丰钵满，也有运气不好的，牛市高点买入，年后经历了断崖式下跌，入坑太深，我经常得负责安慰他们啊。既已入坑就安安心心填坑爬坑吧，如果你相信区块链的价值，那就耐心持有等待黎明吧。现在我用行动来表明对区块链未来的信心，希望在未来和同道的朋友们在区块链领域找到宝藏，挖到宝贝，赚到财富。从今天开始我的新职业：区块链财富猎人。

为什么要all in区块链？

我去年初开始研究区块链，那时候我的朋友还没有人玩，顶多只是听说过比特币，但最近我身边不少在我的鼓动下，或者比特币价格大涨等消息面的影响下，都开始关注区块链，准备跃跃欲试，已经有部分朋友在屯币了，但是在观望找切入点的人更多。我觉得磨叽的人太多了，扣扣索索，畏手畏脚，果敢点，行动力快点，躁动起来，也许早就致富了。再不行动，你就错过了。而我认为：

2018年错过区块链，你可能就错过了一个时代！

政府打压禁止，舆论制造各种负面，吓唬到了我们这些小百姓，但是公司老板们贼精明，都在布局区块链，等待未来到来。看看2017年区块链全球专利申请排名：

前言

人类的发展、科技的进步，都是因为人类对生命质量要求不断提高有关，人类需要光，所以发明了电，人类渴望速度更快，所以发明了汽车飞机高铁，人类想要身体健康寿命更长，所以发明了医学生命科学。

比特币是郁金香泡沫，还是真的代表未来趋势，这个争论的答案是什么，我们可以从货币的发展史得出一些启示，以史为鉴，可以纠正我们的认知。

货币发展不同阶段

货币1.0版 大米等物品的货币初现

提交代码到代码托管平台

既然是开源,要求代码任何人都能够访问,这里选择github,当然也可以用其他平台如oschina等,项目必须是公开项目.比如我的这个:https://github.com/iOSSinger/SGExtension.git

创建spec文件

将代码克隆到本地,如果本地已经存在,直接跳过这一步.
创建.podspec文件,切换到项目根目录,创建spec文件:

//切换到项目根目录

cd SGExtenion

//创建spec文件

pod spec create SGExtension

用xcode打开 SGExtension.podspec,里面有英文注释,我这里直接给简单模板,其实就是去掉了注释,详细的设置看这里

Pod::Spec.new do |spec|

spec.name                  = 'SGExtension'

spec.version               = '1.0.2'

spec.ios.deployment_target = '8.0'

spec.license               = 'MIT'

spec.homepage              = 'https://github.com/iOSSinger'

spec.author                = { "iOSSinger" => "747616044@qq.com" }

spec.summary               = '各种工具的合集'

spec.source                = { :git => 'https://github.com/iOSSinger/SGExtension.git', :tag => spec.version }

spec.source_files          = "SGExtension/**/{*.h,*.m}"

spec.resources             = "SGExtension/source.bundle"

spec.frameworks            = 'UIKit'

spec.library               = 'z'

spec.requires_arc          = true

end

解释下每行的意思:

• spec.name

  名字，pod search 搜索的关键词,注意这里一定要和.podspec的名称一样,否则报错

• spec.version

  版本号

• spec.ios.deployment_target

  支持的ios最低版本

• spec.license

  许可证,一般MIT,这里提醒一下,根目录下必须要有LICENSE这个文件,可以直接把我项目中的copy一份,改下作者名字即可.一般github创建仓库的时候可以选择许可为MIT,会自动帮你生成该文件.

• spec.homepage

  项目主页地址,要求必须能访问

• spec.author

  作者信息

• spec.summary

  项目简介

• spec.source

  项目的地址,填上项目的github地址,tag => spec.version表示git项目的tag值与上面的spec的版本一致,这里是 1.0.2 .

• spec.source_files

  项目源文件,主要是.h和.m文件,

  *表示匹配所有文件
  {.h,.m} 表示匹配所有以.h和.m结尾的文件
  ** 表示匹配所有子目录,以及递归子目录

• spec.resources

  项目所需的资源文件,比如图片

• spec.frameworks

  项目的依赖框架,比如UIKit,不需要后缀名

• spec.library

  项目依赖的库文件(这个是系统的库文件),不需要后缀名,比如sqlite,libz等.以lib开头的需要省略掉lib这三个字母.例如:libz需要简写为z否则报错.

• spec.requires_arc

  是否是arc,一般true

如果你的项目依赖了别的pod项目,可以这样写:

spec.dependency = 'AFNetworking'

提交代码,并打上tag

//提交代码
git push

//打tag
git tag 1.0.2

//将tag推送到远端
git push origin --tags

验证podspec文件

pod spec lint SGExtemnsion.podspec

这一步如果报错,根据错误自行修改,根据大致意思能看出来个大概,终端会给出哪一行出错了.一般就是语法错误,资源找不到,git地址不对或者不能访问.指定的文件如{.h,.m}找不到,一般再检查检查基本没问题.

注册trunk,并提交spec文件cocoapods仓库

• 注册chunk,查看是否注册过

  pod trunk me
  

• 如果没有注册,那么注册:

  pod trunk register 747616044@qq.com "iOSSinger"
  

填上邮箱 和 用户名就可以了.注册完成之后会给你的邮箱发个邮件,进入邮箱邮件里面有个链接,需要点击确认一下.然后再查看下是否注册成功:

pod trunk me

• 提交spec文件到 CocoaPods 中心仓库

  pod trunk push SGExtension.podspec
  

如果前面都没问题,这一步基本也没啥问题.不过网速比较慢可能要等很久,这一步建议翻墙,不然有可能真的很慢.

然后验证一下,是否可以查到

pod search SGExtension

如果能够查到,恭喜你 !,如果查不到,往下看

• 解决方案:

* 查看上一步(提交到代码仓库)是否成功,再次执行提交:

1
pod trunk push SGExtension.podspec


如果出现如下信息:

1
[!] Unable to accept duplicate entry for: SGExtension (1.0.2)


那么说明已经提交到cocoapods仓库成功,那么有可能就是本地仓库没有更新.更新本地仓库:

1
pod repo update

• 再次执行 pod search SGExtension 命令,如果还搜索不到,继续往下看:

  rm ~/Library/Caches/CocoaPods/search_index.json
  

  这句话是移除已经生成的搜索目录缓存文件,移除之后,执行pod search会重新生成一份最新的缓存列表,基本到这里就差不多了.

• 如果还有问题,那就需要终极大招,但是不推荐用,时间很长,除非翻墙.

  pod repo remove master  
  pod setup
  

  或者

  sudo rm -fr ~/.cocoapods/repos/master
  pod setup
  

  这两种写法的意思都是移除本地cocoapods仓库,重新从官网拉取一遍.可能时间比较长,所以不建议用,如果网速度快可以考虑使用,也可以翻墙.整个仓库打下大约500M+(截止当前时间).

集成到项目中试试

target '项目名' do
pod 'SGExtension'
end

多人共同维护你的开源项目

如果需要多个人维护一个库,每个人都应该有权限push提交spec文件;第一个push的人可以被认为是管理员,可以再添加子管理员,这样子管理员就有权限push了

pod trunk add-owner 邮箱地址

移除某个管理员

pod trunk remove-owner 邮箱地址

pod lib lint 和 pod spec lint 有什么区别

• pod lib lint 不需要联网
• pod spec lint 会联网检查sepc repo,并且关联tag

原文出处

cocoapods系列教程—让自己的开源框架支持cocoapods

参考

参考:http://studentdeng.github.io/blog/2013/09/13/cocoapods-tutorial/

介绍

Cocoapods是非常好用的一个iOS依赖管理工具，使用它可以方便的管理和更新项目中所使用到的第三方库，以及将自己的项目中的公共组件交由它去管理。Cocoapods的介绍及优点本文就不在赘述，我开始使用Cocoapods还是在两年前，那个时候它刚刚出现，网上的资料还非常的少，就连他们自己的HomePage都十分的简单，我就着手尝试着使用了一下，用它管理起第三方库确实是十分的方便顺手。后来它有了更强大的功能就是自己创建podspec，更可以设置私有的库。

春节回来上班，一天的工作结束之后，需要充实下自己，正好项目中有一些公共组件需要从庞大的项目体系中剥离出来，而且年前项目终于从SVN迁移到了Git，真是喜大普奔，大快人心！这样项目使用Cocoapods就有了条件，正好学习一下创建私有的podspec并在项目中部署使用，以及pods的subspec的创建及使用。
整体先说明一下创建一个私有的podspec包括如下那么几个步骤：

• 创建并设置一个私有的Spec Repo。
• 创建Pod的所需要的项目工程文件，并且有可访问的项目版本控制地址。
• 创建Pod所对应的podspec文件。
• 本地测试配置好的podspec文件是否可用。
• 向私有的Spec Repo中提交podspec。
• 在个人项目中的Podfile中增加刚刚制作的好的Pod并使用。
• 更新维护podspec。

在这一系列的步骤中需要创建两个Git仓库，分别是第一步和第二步（第二步不一定非要是Git仓库，只要是可以获取到相关代码文件就可以，也可以是SVN的，也可以说zip包，区别就是在podspec中的source项填写的内容不同），并且第一步只是在初次创建私有podspec时才需要，之后在创建其他的只需要从第二步开始就可以。本文只介绍在Git环境下的操作，其他环境其他方式暂不说明。

创建私有Spec Repo

先来说第一步，什么是Spec Repo？他是所有的Pods的一个索引，就是一个容器，所有公开的Pods都在这个里面，他实际是一个Git仓库remote端
在GitHub上，但是当你使用了Cocoapods后他会被clone到本地的~/.cocoapods/repos目录下，可以进入到这个目录看到master文件夹就是这个官方的Spec Repo了。这个master目录的结构是这个样子的

.
├── Specs
    └── [SPEC_NAME]
        └── [VERSION]
            └── [SPEC_NAME].podspec

因此我们需要创建一个类似于master的私有Spec Repo，这里我们可以fork官方的Repo，也可以自己创建，个人建议不fork，因为你只是想添加自己的Pods，没有必要把现有的公开Pods都copy一份。所以创建一个 Git仓库，这个仓库你可以创建私有的也可以创建公开的，不过既然私有的Spec Repo，还是创建私有的仓库吧，需要注意的就是如果项目中有其他同事共同开发的话，你还要给他这个Git仓库的权限。因为GitHub的私有仓库是收费的，我还不是GitHub的付费用户，所以我使用了其他Git服务，我使用的是CODING，当然还有其他的可供选择开源中国、Bitbucket以及CSDN

创建完成之后在Terminal中执行如下命令

# pod repo add [Private Repo Name] [GitHub HTTPS clone URL]
$ pod repo add WTSpecs https://coding.net/wtlucky/WTSpecs.git

此时如果成功的话进入到~/.cocoapods/repos目录下就可以看到WTSpecs这个目录了。至此第一步创建私有Spec Repo完成。

PS：如果有其他合作人员共同使用这个私有Spec Repo的话在他有对应Git仓库的权限的前提下执行相同的命令添加这个Spec Repo即可。

创建Pod项目工程文件

这个第二步没有什么好介绍的，如果是有现有的组件项目，并且在Git的版本管理下，那么这一步就算完成了，可以直接进行下一步了。

如果你的组件还在你冗余庞大的项目中，需要拆分出来或者需要自己从零开始创建一个组件库，那么我建议你使用Cocoapods提供的一个工具将第二步与第三步结合起来做。

现在来说一下这个工具，相关的文档介绍是Using Pod Lib Create 就拿我创建的podTestLibrary为例子具体讲一下这里是如何操作的，先cd到要创建项目的目录然后执行

$ pod lib create podTestLibrary

之后他会问你四个问题，1.是否需要一个例子工程；2.选择一个测试框架；3.是否基于View测试；4.类的前缀；4个问题的具体介绍可以去看官方文档，我这里选择的是1.yes；2.Specta/Expecta；3.yes；4.PTL。 问完这4个问题他会自动执行pod install命令创建项目并生成依赖。

$ tree PodTestLibrary -L 2
PodTestLibrary
├── Example                                  #demo APP
│   ├── PodTestLibrary
│   ├── PodTestLibrary.xcodeproj
│   ├── PodTestLibrary.xcworkspace
│   ├── Podfile                              #demo APP 的依赖描述文件
│   ├── Podfile.lock
│   ├── Pods                                  #demo APP 的依赖文件
│   └── Tests
├── LICENSE                               #开源协议 默认MIT
├── Pod                                       #组件的目录
│   ├── Assets                            #资源文件
│   └── Classes                              #类文件
├── PodTestLibrary.podspec           #第三步要创建的podspec文件
└── README.md                                #markdown格式的README

9 directories, 5 files

以上是项目生成的目录结构及相关介绍。

接下来就是向Pod文件夹中添加库文件和资源，并配置podspec文件，我把一个网络模块的共有组件放入Pod/Classes中，然后进入Example文件夹执行pod update命令，再打开项目工程可以看到，刚刚添加的组件已经在Pods子工程下Development Pods/PodTestLibrary中了，然后编辑demo工程，测试组件，我并没有使用提供的测试框架进行测试，这里就先不介绍了。

注：这里需要注意的是每当你向Pod中添加了新的文件或者以后更新了podspec的版本都需要重新执行一遍pod update命令。

测试无误后需要将该项目添加并推送到远端仓库，并编辑podspec文件。

通过Cocoapods创建出来的目录本身就在本地的Git管理下，我们需要做的就是给它添加远端仓库，同样去GitHub或其他的Git服务提供商那里创建一个私有的仓库，拿到SSH地址，然后cd到PodTestLibrary目录

$ git add .
$ git commit -s -m "Initial Commit of Library"
$ git remote add origin git@coding.net:wtlucky/podTestLibrary.git           #添加远端仓库
$ git push origin master     #提交到远端仓库

因为podspec文件中获取Git版本控制的项目还需要tag号，所以我们要打上一个tag，

$ git tag -m "first release" 0.1.0
$ git push --tags     #推送tag到远端仓库

做完这些就可以开始编辑podspec文件了，它是一个Ruby的文件，把编辑器的格式改成Ruby就能看到语法高亮，下面我贴上我的podspec文件，并在后面以注释的形式说明每个字段的含义，没有涉及到的字段可以去官方文档查阅

Pod::Spec.new do |s|
  s.name             = "PodTestLibrary"    #名称
  s.version          = "0.1.0"             #版本号
  s.summary          = "Just Testing."     #简短介绍，下面是详细介绍
  s.description      = <<-DESC
                       Testing Private Podspec.

                       * Markdown format.
                       * Don't worry about the indent, we strip it!
                       DESC
  s.homepage         = "https://coding.net/u/wtlucky/p/podTestLibrary"                           #主页,这里要填写可以访问到的地址，不然验证不通过
  # s.screenshots     = "www.example.com/screenshots_1", "www.example.com/screenshots_2"           #截图
  s.license          = 'MIT'              #开源协议
  s.author           = { "wtlucky" => "wtlucky@foxmail.com" }                   #作者信息
  s.source           = { :git => "https://coding.net/wtlucky/podTestLibrary.git", :tag => "0.1.0" }      #项目地址，这里不支持ssh的地址，验证不通过，只支持HTTP和HTTPS，最好使用HTTPS
  # s.social_media_url = 'https://twitter.com/<TWITTER_USERNAME>'                       #多媒体介绍地址

  s.platform     = :ios, '7.0'            #支持的平台及版本
  s.requires_arc = true                   #是否使用ARC，如果指定具体文件，则具体的问题使用ARC

  s.source_files = 'Pod/Classes/**/*'     #代码源文件地址，**/*表示Classes目录及其子目录下所有文件，如果有多个目录下则用逗号分开，如果需要在项目中分组显示，这里也要做相应的设置
  s.resource_bundles = {
    'PodTestLibrary' => ['Pod/Assets/*.png']
  }                                       #资源文件地址

  s.public_header_files = 'Pod/Classes/**/*.h'   #公开头文件地址
  s.frameworks = 'UIKit'                  #所需的framework，多个用逗号隔开
  s.dependency 'AFNetworking', '~> 2.3'   #依赖关系，该项目所依赖的其他库，如果有多个需要填写多个s.dependency
end

编辑完podspec文件后，需要验证一下这个文件是否可用，如果有任何WARNING或者ERROR都是不可以的，它就不能被添加到Spec Repo中，不过xcode的WARNING是可以存在的，验证需要执行一下命令

$ pod lib lint

当你看到

 -> PodTestLibrary (0.1.0)

PodTestLibrary passed validation.

时，说明验证通过了，不过这只是这个podspec文件是合格的，不一定说明这个Pod是可以用的，我们需要在本地做一下验证，这就是第四步的内容了，第四步在具体说明。

创建podspec文件

如果从第二步过来，已经有了现成的项目，那么就需要给这个项目创建一个podspec文件，创建它需要执行Cocoapods的另外一个命令，官方文档在这里

$ pod spec create PodTestLibrary git@coding.net:wtlucky/podTestLibrary.git

执行完之后，就创建了一个podspec文件，他其中会包含很多内容，可以按照我之前介绍的进行编辑，没用的删掉。编辑完成之后使用验证命令验证一下

$ pod lib lint

验证无误就可以进入下一步了。

本地测试podspec文件

我们可以创建一个新的项目，在这个项目的Podfile文件中直接指定刚才创建编辑好的podspec文件，看是否可用。 在Podfile中我们可以这样编辑，有两种方式

platform :ios, '7.0'

pod 'PodTestLibrary', :path => '~/code/Cocoapods/podTest/PodTestLibrary'      # 指定路径
pod 'PodTestLibrary', :podspec => '~/code/Cocoapods/podTest/PodTestLibrary/PodTestLibrary.podspec'  # 指定podspec文件

然后执行pod install命令安装依赖，打开项目工程，可以看到库文件都被加载到Pods子项目中了，不过它们并没有在Pods目录下，而是跟测试项目一样存在于Development Pods/PodTestLibrary中，这是因为我们是在本地测试，而没有把podspec文件添加到Spec Repo中的缘故。

在项目中编写代码，测试库文件无误后就可以开始下一步了，提交podspec到Spec Repo中。

向Spec Repo提交podspec

向Spec Repo提交podspec需要完成两点一个是podspec必须通过验证无误，在一个就是删掉无用的注释（这个不是必须的，为了规范还是删掉吧）。 向我们的私有Spec Repo提交podspec只需要一个命令

$ pod repo push WTSpecs PodTestLibrary.podspec  #前面是本地Repo名字 后面是podspec名字

完成之后这个组件库就添加到我们的私有Spec Repo中了，可以进入到~/.cocoapods/repos/WTSpecs目录下查看

.
├── LICENSE
├── PodTestLibrary
│   └── 0.1.0
│       └── PodTestLibrary.podspec
└── README.md

再去看我们的Spec Repo远端仓库，也有了一次提交，这个podspec也已经被Push上去了。

至此，我们的这个组件库就已经制作添加完成了，使用pod search命令就可以查到我们自己的库了

$ pod search PodTestLibrary

-> PodTestLibrary (0.1.0)
   Just Testing.
   pod 'PodTestLibrary', '~> 0.1.0'
   - Homepage: https://coding.net/u/wtlucky/p/podTestLibrary
   - Source:   https://coding.net/wtlucky/podTestLibrary.git
   - Versions: 0.1.0 [WTSpecs repo]

这里说的是添加到私有的Repo，如果要添加到Cocoapods的官方库了，可以使用trunk工具，具体可以查看官方文档

使用制作好的Pod

在完成这一系列步骤之后，我们就可以在正式项目中使用这个私有的Pod了只需要在项目的Podfile里增加以下一行代码即可

$ pod 'PodTestLibrary', '~> 0.1.0'

然后执行pod update，更新库依赖，然后打卡项目可以看到，我们自己的库文件已经出现在Pods子项目中的Pods子目录下了，而不再是Development Pods。

更新维护podspec

最后再来说一下制作好的podspec文件后续的更新维护工作，比如如何添加新的版本，如何删除Pod。

我已经制作好了PodTestLibrary的0.1.0版本，现在我对他进行升级工作，这次我添加了更多的模块到PodTestLibrary之中，包括工具类，底层Model及UIKit扩展等，这里又尝试了一下subspec功能，给PodTestLibrary创建了多个子分支。

具体做法是先将源文件添加到Pod/Classes中，然后按照不同的模块对文件目录进行整理，因为我有四个模块，所以在Pod/Classes下有创建了四个子目录，完成之后继续编辑之前的PodTestLibrary.podspec，这次增加了subspec特性

Pod::Spec.new do |s|
  s.name             = "PodTestLibrary"
  s.version          = "1.0.0"
  s.summary          = "Just Testing."
  s.description      = <<-DESC
                       Testing Private Podspec.

                       * Markdown format.
                       * Don't worry about the indent, we strip it!
                       DESC
  s.homepage         = "https://coding.net/u/wtlucky/p/podTestLibrary"
  # s.screenshots     = "www.example.com/screenshots_1", "www.example.com/screenshots_2"
  s.license          = 'MIT'
  s.author           = { "wtlucky" => "wtlucky@foxmail.com" }
  s.source           = { :git => "https://coding.net/wtlucky/podTestLibrary.git", :tag => "1.0.0" }
  # s.social_media_url = 'https://twitter.com/<TWITTER_USERNAME>'

  s.platform     = :ios, '7.0'
  s.requires_arc = true

  #s.source_files = 'Pod/Classes/**/*'
  #s.resource_bundles = {
  #  'PodTestLibrary' => ['Pod/Assets/*.png']
  #}
  #s.public_header_files = 'Pod/Classes/**/*.h'

  s.subspec 'NetWorkEngine' do |networkEngine|
      networkEngine.source_files = 'Pod/Classes/NetworkEngine/**/*'
      networkEngine.public_header_files = 'Pod/Classes/NetworkEngine/**/*.h'
      networkEngine.dependency 'AFNetworking', '~> 2.3'
  end

  s.subspec 'DataModel' do |dataModel|
      dataModel.source_files = 'Pod/Classes/DataModel/**/*'
      dataModel.public_header_files = 'Pod/Classes/DataModel/**/*.h'
  end

  s.subspec 'CommonTools' do |commonTools|
      commonTools.source_files = 'Pod/Classes/CommonTools/**/*'
      commonTools.public_header_files = 'Pod/Classes/CommonTools/**/*.h'
      commonTools.dependency 'OpenUDID', '~> 1.0.0'
  end

  s.subspec 'UIKitAddition' do |ui|
      ui.source_files = 'Pod/Classes/UIKitAddition/**/*'
      ui.public_header_files = 'Pod/Classes/UIKitAddition/**/*.h'
      ui.resource = "Pod/Assets/MLSUIKitResource.bundle"
      ui.dependency 'PodTestLibrary/CommonTools'
  end

  s.frameworks = 'UIKit'
  #s.dependency 'AFNetworking', '~> 2.3'
  #s.dependency 'OpenUDID', '~> 1.0.0'
end

因为我们创建了subspec所以项目整体的依赖dependency，源文件source_files，头文件public_header_files，资源文件resource等都移动到了各自的subspec中，每个subspec之间也可以有相互的依赖关系，比如UIKitAddition就依赖于CommonTools。

编辑完成之后，在测试项目里pod update一下，几个子项目都被加进项目工程了，写代码验证无误之后，就可以将这个工程push到远端仓库，并打上新的tag->1.0.0。

最后再次使用pod lib lint验证编辑好的podsepc文件，没有自身的WARNING或者ERROR之后，就可以再次提交到Spec Repo中了，命令跟之前是一样的

$ pod repo push WTSpecs PodTestLibrary.podspec

之后再次到~/.cocoapods/repos/WTSpecs目录下查看

.
├── LICENSE
├── PodTestLibrary
│   ├── 0.1.0
│   │   └── PodTestLibrary.podspec
│   └── 1.0.0
│       └── PodTestLibrary.podspec
└── README.md

3 directories, 4 files

已经有两个版本了，使用pod search查找得到的结果为

$ pod search PodTestLibrary

-> PodTestLibrary (1.0.0)
   Just Testing.
   pod 'PodTestLibrary', '~> 1.0.0'
   - Homepage: https://coding.net/u/wtlucky/p/podTestLibrary
   - Source:   https://coding.net/wtlucky/podTestLibrary.git
   - Versions: 1.0.0, 0.1.0 [WTSpecs repo]
   - Sub specs:
     - PodTestLibrary/NetWorkEngine (1.0.0)
     - PodTestLibrary/DataModel (1.0.0)
     - PodTestLibrary/CommonTools (1.0.0)
     - PodTestLibrary/UIKitAddition (1.0.0)

完成这些之后，在实际项目中我们就可以选择使用整个组件库或者是组件库的某一个部分了，对应的Podfile中添加的内容为

source 'https://github.com/CocoaPods/Specs.git'  # 官方库
source 'https://git.coding.net/wtlucky/WTSpecs.git'   # 私有库
platform :ios, '7.0'

pod 'PodTestLibrary/NetWorkEngine', '1.0.0'  #使用某一个部分
pod 'PodTestLibrary/UIKitAddition', '1.0.0'

pod 'PodTestLibrary', '1.0.0'   #使用整个库

最后介绍一下如何删除一个私有Spec Repo，只需要执行一条命令即可

$ pod repo remove WTSpecs

这样这个Spec Repo就在本地删除了，我们还可以通过

$ pod repo add WTSpecs git@coding.net:wtlucky/WTSpecs.git

再把它给加回来。

如果我们要删除私有Spec Repo下的某一个podspec怎么操作呢，此时无需借助Cocoapods，只需要cd到~/.cocoapods/repos/WTSpecs目录下，删掉库目录

wtlucky@wtluckydeMacBook-Pro:~/.cocoapods/repos/WTSpecs$ rm -Rf PodTestLibrary

然后在将Git的变动push到远端仓库即可

wtlucky@wtluckydeMacBook-Pro:~/.cocoapods/repos/WTSpecs$ git add --all .
wtlucky@wtluckydeMacBook-Pro:~/.cocoapods/repos/WTSpecs$ git ci -m "remove unuseful pods"
wtlucky@wtluckydeMacBook-Pro:~/.cocoapods/repos/WTSpecs$ git push origin master

参考资料

Private Pods

Creating a Private CocoaPod

Developing Private In-House Libraries with CocoaPods

一个简单的Podfile

target 'MyApp'
pod 'AFNetworking', '~> 1.0'

一个复杂的Podfile

platform :ios, '9.0'
inhibit_all_warnings!

target "MyApp" do
  pod 'ObjectiveSugar', '~> 0.5'

  target "MyAppTests" do
    inherit! :search_paths
    pod 'OCMock', '~> 2.0.1'
  end
end


post_install do |installer|
  installer.pods_project.targets.each do |target|
    puts "#{target.name}"
  end
end

根节点配置项

install!

pod install执行时的一些设置。
示例：

install! 'cocoapods',
:deterministic_uuids => false,
:integrate_targets => false

支持关键字：
:clean
:deduplicate_targets
:deterministic_uuids
:integrate_targets
:lock_pod_sources

依赖

pod

// 使用最新版本
pod 'SSZipArchive'
// 使用指定版本
pod 'Objection', '0.9'
‘> 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.2.0’
‘~> 0.1’ 相当于'>= 0.1 且 ‘< 1.0’
‘~> 0’ 相当于不写，即最新版本

编译配置

// 在Release和App Store模式引用该库
pod 'PonyDebugger', :configurations => ['Release', 'App Store']
// 在Release模式引用该库
pod 'PonyDebugger', :configuration => ['Release']

Subspecs
在使用开源库时，只是用该库的一部分，可是使用如下写法。前提是当前库是支持Subspecs的。

// 只引用QueryKit的Attribute子库，不包含其它子库
pod 'QueryKit/Attribute'
// 只引用QueryKit的Attribute和QuerySet子库，不包含其它子库
pod 'QueryKit', :subspecs => ['Attribute', 'QuerySet']

使用本地路径下的文件

pod 'AFNetworking', :path => '~/Documents/AFNetworking'

使用已通过认证的repo

// 使用master分支
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git'
// 使用指定分支
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :branch => 'dev'
// 使用指定tag
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :tag => '0.7.0'
// 使用某一次提交
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :commit => '082f8319af'

指定podspec文件
pod ‘JSONKit’, :podspec => ‘https://example.com/JSONKit.podspec'

podspec

指定需要加载的podspec

podspec
podspec :name => 'QuickDialog'
podspec :path => '/Documents/PrettyKit/PrettyKit.podspec'

target

定义一个依赖库与target（Xcode project）的关系。每个target应该对应一个Xcode target。默认情况下，子target的依赖关系是包含父target的，除非指定非继承父target。
定义一个target

target "ZipApp" do
  pod 'SSZipArchive'
end

在父target中定义SSZipArchive pod，仅支持父target

target "ZipApp" do
  pod 'SSZipArchive'

  target "ZipAppTests" do
    inherit! :search_paths
    pod 'Nimble'
  end
end

通过在父target中定义target应用Pods支持多个targets

target "ShowsApp" do
  pod 'ShowsKit'

  # Has it's own copy of ShowsKit + ShowTVAuth
  target "ShowsTV" do
    pod "ShowTVAuth"
  end

  # Has it's own copy of Specta + Expecta
  # and has access to ShowsKit via the app
  # that the test target is bundled into

  target "ShowsTests" do
    inherit! :search_paths
    pod 'Specta'
    pod 'Expecta'
  end
end

abstract_target

定义一个abstract_target，方便被所有继承target使用。
定义abstract_target

abstract_target 'Networking' do
  pod 'AlamoFire'

  target 'Networking App 1'
  target 'Networking App 2'
end

定义一个abstract_target包含多个targets

# There are no targets called "Shows" in any Xcode projects
abstract_target "Shows" do
  pod 'ShowsKit'

  # Has it's own copy of ShowsKit + ShowWebAuth
  target "ShowsiOS" do
    pod "ShowWebAuth"
  end

  # Has it's own copy of ShowsKit + ShowTVAuth
  target "ShowsTV" do
    pod "ShowTVAuth"
  end

  # Has it's own copy of Specta + Expecta
  # and has access to ShowsKit via the app
  # that the test target is bundled into

  target "ShowsTests" do
    inherit! :search_paths
    pod 'Specta'
    pod 'Expecta'
  end
end

abstract!
表示当前target是抽象的，不会与真正的Xcode target挂钩。

inherit!
设置当前target的继承模式。

// Inheriting only search paths
target 'App' do
  target 'AppTests' do
    inherit! :search_paths
  end
end

Target配置

这些设置是控制被生成project的CocoaPods。包括指定编译platform、指定链接的xcodeproj。

platform

如果不指定，CocosPods将是默认值，当前默认值是：
4.3 for iOS, 10.6 for OS X, 9.0 for tvOS and 2.0 for watchOS.
如果对系统有要求（iOS < 4.3）,armv6 框架将添加至ARCHS.
platform :ios, “4.0”
platform :ios

project

指定当前target链接的project。若未指定，表示target链接与同路径（与podfile文件同路径）下target同名的project。
指定用户project

# This Target can be found in a Xcode project called `FastGPS`
target "MyGPSApp" do
  project 'FastGPS'
  ...
end

# Same Podfile, multiple Xcodeprojects
target "MyNotesApp" do
  project 'FastNotes'
  ...
end

有户自定义编译设置

project 'TestProject', 'Mac App Store' => :release, 'Test' => :debug

xcodeproj

xcodeproj已在1.0中弃用，并已重命名project。对于1.0版之前的版本xcodeproj。

link_with

link_with在1.0中被弃用，使用abstract_target和target继承替代。

inhibit_all_warnings!

禁止CocoaPods库的所有警告。该属性会被子target继承。

pod 'SSZipArchive', :inhibit_warnings => true
pod 'SSZipArchive', :inhibit_warnings => false

use_frameworks!

用frameworks 替代Pods静态库。该属性被子target继承。

Workspace

workspace

指定workspace。若未指定，表示是与podfile同路径下，且与target同名的workspace文件。例如：

workspace 'MyWorkspace'

generate_bridge_support!

指定应从所有安装的Pod的头文件中生成一个BridgeSupport元数据文档。
这是用于脚本语言，如MacRuby， Nu和 JSCocoa，它用于桥接类型，功能等。

set_arc_compatibility_flag!

已经被CocoaPods 1.0放弃。

Source

指定资源位置。

source 'https://github.com/artsy/Specs.git'
source 'https://github.com/CocoaPods/Specs.git'

Hooks

Podfile提供在安装期间执行的hooks,hooks是全局的，不存在为单个target定义hook。

plugin

指定安装期间需要的插件。

plugin 'cocoapods-keys', :keyring => 'Eidolon'
plugin 'slather'

pre_install

Hook允许用户在Pods下载完成，但还未安装前对Pods做一些修改。
它接受 Pod::Installer 作为唯一的参数.

在Podfile定义pre-install hook

pre_install do |installer|
  # Do something fancy!
end

post_install

Hook允许用户在被写入硬盘、或者任何你想做的其它任务之前，对生成的Xcode project做最后的改变。
它接受 Pod::Installer 作为唯一的参数.
例如：

Customising the build settings of all targets
post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['GCC_ENABLE_OBJC_GC'] = 'supported'
    end
  end
end

CocoaPods入门

CocoaPods是什么

CocoaPods是一个用来管理Xcode项目依赖库的工具。

你的项目依赖库需要被详细列在一个叫Profile的文件中。CocoaPods将帮我们解决libraries之间的依赖关系、获取目标库的源码、并将它链接到Xcode workspace中来构建你的项目。
最终目标是通过建立一个查找效率更高、更规范的第三方开源库生态系统。

安装CocoaPods

CocoaPods是基于Ruby开发的，通过OS X 默认可用的Ruby安装。

$ sudo gem install cocoapods

在安装过程中遇到任何问题，请查看此处。

升级CocoaPods

只要再执行安装gem命令就可以升级你的CocoaPods

$ [sudo] gem install cocoapods // 正式发布版本

可以使用如下命令来更新到预发布版本，如果预发布版本存在的话

$ [sudo] gem install cocoapods --pre // 预发布版本

如果你在安装时使用了sudo，那你应该再次使用这个命令。

之后，在你使用Cocoapods安装依赖库的时候，如果有新版CocoaPods时，你就会收到通知告知你CocoaPods X.X.X已经用了，请更新的信息。

使用CocoaPods

在已有项目中使用CocoaPods

前提

1. 已经安装CocoaPods
2. 通过Specs仓库或cocoapods.org确定将要被引用的资源是可用的

第一步、创建Podfile文件，并添加依赖库。

target 'MyApp' do
      pod 'AFNetworking', '~> 3.0'

      pod 'FBSDKCoreKit', '~> 4.9'
end

第二步、终端进入Podfile文件所在目录，运行pod install

pod install

第三步、打开新生成的**.xcworkspace文件，继续开发。

使用CocoaPods创建一个新项目

使用CocoaPods创建一个新项目，步骤如下：

第一步、正常创建一个项目

第二步、通过终端进入项目目录。

$ cd your project directory

第三步、创建Podfile。

$ pod init

第四步、创建Podfile，可以通过pod init命令创建。

$ pod init

• 首先 输入平台及版本，如：platform :ios, ‘9.0’

• 其次 指定项目。以target ‘$TARGET_NAME’ do开始，以end结束。

• 而后 添加依赖资源。pod ‘$PODNAME’

target 'MyApp' do

      pod 'ObjectiveSugar'

end

第五步、保存Podfile，终端运行

$ pod install

第六步、打开新创建的 MyApp.xcworkspace文件，以后每次打开项目都是这种方式。

在已有workspace中使用CocoaPods

在Podfile文件中加入一行信息，指定workspace。

workspace 'MyWorkspace'

什么时候使用pod install 什么时候使用pod update？

很多人对于什么时候使用pod install 什么时候使用pod update有困惑，尤其当本该使用pod install的时候他们却使用了pod update。

你可以在这篇专题文章中找到具体解释何时使用他们，并且使用他们的目的。

是否需要将Pods目录加入代码版本管理？

是否将你的Pods文件夹加入版本管理取决于你，因为每个项目的工作流是不同的。我们建议你将Pods目录进行版本控制，不要把它加入到.gitignore文件中，但是最终这取决于你。

将Pods目录加入版本管理的好处

• 在科隆仓库后，项目可以立即被构建和运行，甚至不需要在本机上安装CocoaPods。不需要运行pod install，也不需要网络。

• pod里的工具（代码和库）都是可用的，即便一个pod的源连接不上。

• 在科隆后可以确保Pod里的工具跟执行过pod install的人的一模一样。

忽略Pods目录的好处

• 版本控制仓库占用的磁盘空间更少更小。

• 当所有的pods可以使用时，CocoaPods将可以再次创建相同的安装。（技术上当在Podfile中不使用提交SHA值的时候不能确保执行pod install命令将获取或者重新创建一样的工具）

• 当执行版本控制操作时不会有任何冲突，比如在不同pod版本中执行合并分支。

无论是否加入版本管理，Podfile和Podfile.lock都应当加入版本控制。

What is Podfile.lock?

当第一次执行pod install的时候会生成这个文件，它会跟踪已经安装的每个pod，比如，下面的依赖列在Podfile里：

pod 'RestKit'

执行pod install命令将安装当前版本的RestKit，并生成Podfile.lock并列出确切安装的版本（比如 RestKit 0.10.3）。多亏podifle.lock,这样我们随后在其他机器上执行pod install会安装 RestKit 0.10.3，即便有其他的新版本可以使用。CocoaPods将会在Podfile.lock中标记Pod版本，除非在podfile里更新了依赖或者执行了pod update命令（它将生成的新的Podfile.lock）。通过这个方式CocoaPods避免了意外的依赖更改导致的问题。

使用CocoaPods时，背后究竟发生了什么

在Xcode中，直接可以引用ruby源，它将:

1. 创建并更新一个workspace.
2. 如果需要的话将你的项目加入到workspace。
3. 如果需要将CocoaPods静态库项目加入到workspace。
4. 将libPods.a添加到库的targets => build phases => link。
5. 将CocoaPods的Xcode配置添加到你的app’s项目中。
6. 修改你APP项目的target配置为基于CocoaPod的。
7. 将你安装的到你APP项目的所有的pod中的资源文件拷贝添加到build phase。比如其他build phase后的‘Script build phase’，如下：
   • Shell: /bin/sh
   • Script: ${SRCROOT}/Pods/PodsResources.sh

Note that steps 3 onwards are skipped if the CocoaPods static library is already in your project. This is largely based on Jonah Williams’ work on Static Libraries.

注意上面的步骤3将会被跳过，如果CocoaPods静态库已经在你的项目的话，这很大一部分是由Jonah Williams处理静态库的方式导致。

从子模块迁移到Pods

CocoaPods和git 子模块都是为了解决相似的问题。他们都致力于简化第三方库代码的处理流程。子模块指向某个项目的特定提交，然而CocoaPods则和版本了的开发者发布版关联在一起。

从子模块切换到CocoaPods

在你决定是否完全切换到CocoaPods时，确保你当前使用的库可用。记录你当前使用的库的版本想法的对的。这样你可以使用一样的库来初始化CocoaPods。最好逐步使用他们，通过一个依赖一个依赖去做而不是一个大的改变。

1. 如果你没有安装CocoaPods的话先安装一下。
2. 创建Podfile文件。
3. 移除子模块的引用。
4. 在Podfile中添加删除库的引用
5. 执行pod install

Podfile文件精讲

Podfile文件是描述一个或者多个Xcode项目target的依赖的详细说明。这个文件必须命名为Podfile。下文和之前的的例子是基于CocoaPods 1.0版本。

一个简单的podfile文件

target 'MyApp' do
  pod 'AFNetworking', '~> 3.0'
end

一个复杂的podfile文件管理一个APP和他一个测试工程(bundle)

source 'https://github.com/CocoaPods/Specs.git'
source 'https://github.com/Artsy/Specs.git'

platform :ios, '9.0'
inhibit_all_warnings!

target 'MyApp' do
  pod 'GoogleAnalytics', '~> 3.1'

  # Has it's own copy of OCMock
  # and has access to GoogleAnalytics via the app
  # that hosts the test target

  target 'MyAppTests' do
    inherit! :search_paths
    pod 'OCMock', '~> 2.0.1'
  end
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    puts target.name
  end
end

如果你希望使用多个target来分享同一个pods，可以使用abstract_target。

使用abstract_target
# There are no targets called "Shows" in any Xcode projects
abstract_target 'Shows' do
  pod 'ShowsKit'
  pod 'Fabric'

  # Has it's own copy of ShowsKit + ShowWebAuth
  target 'ShowsiOS' do
    pod 'ShowWebAuth'
  end

  # Has it's own copy of ShowsKit + ShowTVAuth
  target 'ShowsTV' do
    pod 'ShowTVAuth'
  end
end

在Podfile根下包含一个抽象的target，因此你也可以这样写：

pod 'ShowsKit'
pod 'Fabric'

# Has it's own copy of ShowsKit + ShowWebAuth
target 'ShowsiOS' do
  pod 'ShowWebAuth'
end

# Has it's own copy of ShowsKit + ShowTVAuth
target 'ShowsTV' do
  pod 'ShowTVAuth'
end

从0.x到1.0的迁移

另外一篇文章深度讲解这个。

具体给出pod版本

pod 'Objection', '0.9'

• ‘> 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.2.0’
• ‘~> 0.1’ 相当于’>= 0.1 且 ‘< 1.0’
• ‘~> 0’ 相当于不写，即最新版本

使用本地路径下的文件

pod 'AFNetworking', :path => '~/Documents/AFNetworking'

使用库所在仓库根路径下的podspec

// 使用master分支
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git'
// 使用指定分支
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :branch => 'dev'
// 使用指定tag
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :tag => '0.7.0'
// 使用某一次提交
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git', :commit => '082f8319a

撤消更改

本教程提供了操作软件项目版本管理所需的所有必要技能。首先，这篇文章会告诉我们如何查看旧的提交，然后解释在项目历史记录中还原公共提交与重置本地计算机上未发布的更改之间的区别。

git checkout

git checkout命令提供三个不同的功能：检出文件，检出提交和检出分支。在这篇文章中，我们只关心前两个配置。

检出提交将使整个工作目录匹配该提交。这可以用来查看您的项目的旧状态，而无需以任何方式更改您当前的状态。检出一个文件可以看到该特定文件的旧版本，使其余的工作目录保持不变。

用法

git checkout master

检出主分支。分支将在下一篇中进行深入研究，但现在您可以将其视为恢复项目“当前”状态的一种方式。

git checkout <commit> <file>

Check out a previous version of a file. This turns the that resides in the working directory into an exact copy of the one from and adds it to the staging area.

检出一个文件的以前的版本。这将工作目录中转换成一个提交时的该文件的精确副本，并将其添加到暂存区。

git checkout <commit>

更新工作目录中的所有文件以匹配指定的提交。您可以使用提交的哈希值或标标签作为参数。这将使您处于分离的HEAD状态。

讨论

任何版本控制系统背后的整个目的是“安全”存储项目的副本，以便您无需担心破坏您的代码库。一旦建立了项目历史记录，git checkout就可以将这些保存的快照“加载”到开发机器上。

检出旧的提交是一个只读操作。查看旧修订版时不可能损害您的存储库。您的在master
分支中项目的“当前”状态保持不变（有关详细信息，请参阅分支模块）。在正常的开发过程中，HEAD
通常指向主或其他本地分支，但是当您检出以前的提交时，HEAD可能不再指向分支，它会直接指向提交。这被称为“分离HEAD”状态，它可以被看成如下：

On the other hand, checking out an old file does affect the current state of your repository. You can re-commit the old version in a new snapshot as you would any other file. So, in effect, this usage of git checkout serves as a way to revert back to an old version of an individual file.

另一方面，检出一个旧文件确实会影响您的仓库的当前状态。您可以像任何其他文件一样在新快照中重新提交旧版本。所以，实际上，git checkout这种用法可以作为恢复单个文件到旧版的一种方式。

示例

查看旧版本

此示例假设您已经开始开发一个疯狂的实验，但您不确定是否要保留。为了帮助您决定，您需要在开始实验之前先了解项目的状态。首先，您需要找到要查看的修订版本的ID。

git log --oneline

假设您的项目历史记录如下所示：

b7119f2 Continue doing crazy things
872fa7e Try something crazy
a1e8fb5 Make some important changes to hello.py
435b61d Create hello.py
9773e52 Initial import

您可以使用以下git checkout方式查看“Make some important changes”的提交：

git checkout a1e8fb5

这使您的工作目录与a1e8fb5提交的确切状态相匹配。您可以查看文件，编译项目，运行测试，甚至编辑文件，而不用担心丢失项目的当前状态。您在这里做的任何事情都将保存在您的仓库中。要继续开发，您需要回到项目的“当前”状态：

git checkout master

这假设您正在开发默认的主分支，这将在《Git分支》中进行详细讨论。一旦你回到主分支，你可以使用任何一个git revert或者git reset撤消任何不需要的更改。

检出文件

如果您只对单个文件感兴趣，您也可以使用它git checkout来获取旧版本。例如，如果您只想hello.py从旧提交中查看文件，则可以使用以下命令：

git checkout a1e8fb5 hello.py

记住，与检出提交不同，这确实会影响项目的当前状态。旧文件修订版将显示为“要进行的更改（Change to be committed）”，让您有机会恢复到以前的文件版本。如果您决定不想保留旧版本，可以使用以下内容检出回最新版本：

git checkout HEAD hello.py

git还原 (git revert)

git revert命令撤销已提交的快照。但是，它不会从项目历史记录中删除提交，它会找出如何撤消引入的修改的提交，并提供追加一个新的提交来实现撤销修改的结果。这样可以防止Git丢失历史记录，这对于修订历史的完整性和可靠的协作非常重要。

用法

git revert <commit>

生成一个新的提交，撤消所有引入的更改，然后将其应用到当前分支。

讨论

当您要从项目历史记录中删除整个提交时，应使用git revert。这可能是有用的，例如，如果您正在跟踪一个错误，并发现它是由某个提交引入的。可以不用手动修改，修复它，并提交新的快照，您可以使用git revert来自动为您搞定。

还原与重置

了解git revert是如何撤消单个提交的这点很重要 - 它不会通过删除所有后续提交来“还原”回项目的先前状态。在Git中，这种做法实际上被称为重置 reset ，而不是还原（revert）。

与重置相比，还原有两个重要的优点。首先，它不会更改项目历史记录，这将使它成为已经发布到公共仓库的提交的“安全”操作。有关为什么更改公共历史记录是危险的详细信息，请参阅git reset 。

第二，git revert能够在历史上的任意位置选择某个提交，而git reset只能从当前提交中选择更早的提交。例如，如果要使用git reset撤消一个旧的提交，则必须删除目标提交之后发生的所有提交，然后将这个删除，然后重新提交这个提交后的所有后续提交。不用说，这不是一个优雅的解决方案。

示例

以下示例是一个简单的示范git revert。它提交快照，然后立即将其还原。

# Edit some tracked files
# Commit a snapshot
git commit -m "Make some changes that will be undone"
# Revert the commit we just created
git revert HEAD

这可以被视为如下所示：

请注意，第4个提交仍然在还原后的项目历史中。git revert不会删除这个提交，而是添加一个新的提交来撤消其更改。因此，第3和第5个提交代表完全相同的代码，第四个提交仍然在我们的历史，以防我们想要回滚到它。

git reset (git重置)

如果git revert是一个“安全”的方式撤消更改，你能想到的git reset就是一个危险的方法。当您使用git reset撤消（并且提交不再被任何引用或reflog引用）时，无法检索原始副本 - 它是永久撤消。使用此工具时必须小心，因为它是唯一可能失去工作的Git命令之一。

像git checkout，git reset是一个多用途的命令并许多配置项。它可以用于删除提交的快照，尽管它更常用于撤销暂存区域和工作目录中的更改。在任何一种情况下，它只能用于撤消本地更改 - 您不应该重置已与其他开发人员共享的快照。

用法

git reset <file>

从暂存区中删除指定的文件，但保持工作目录不变。这不会覆盖文件而不会覆盖任何更改。

git reset

重置暂存区以匹配最近的提交，但保持工作区不变。这不会覆盖任何更改，并让所有文件处于非暂存状态，从而让您有机会从头开始重新构建暂存快照。

git reset --hard

重置暂存区和工作目录以匹配最近的提交。包括没有暂存的更改，该–hard标志还会让Git覆盖工作目录中的所有更改。换句话说，这样会抹去所有未提交的变更，所以请确保在使用之前，确实希望废弃您的本地开发工作。

git reset <commit>

将当前分支提示向后移动，重置暂存区以匹配，但将工作区单独保留。之后所做的所有更改将放在工作区中，从而可以使用更干净，更原子的快照重新提交项目历史记录。

git reset --hard <commit>

将当前分支提示向后移动刀位置，并重置暂存区域和工作区以匹配该提交。这不仅消除了未提交的变更，也包括全部之后的提交。

讨论

所有上述方法都用于从仓库中删除更改。如果没有–hard标志，git reset是一种通过让修改和将一系列提交改为未提交的方式来清理仓库的方法。当一个实验发生可怕的错误，你需要一个完全放弃这些内容的时候使用–hard。

而还原被设计为安全地撤销公共提交，git reset旨在撤消本地更改。由于其不同的目标，两个命令的实现方式不同：重置完全删除了一系列修改，而还原维护原始的更改集，并使用一个新的提交来应用撤消。

不要在公共仓库使用git reset

绝对不要在公共仓库使用git reset。发布提交后，您必须假设其他开发人员依赖它。

删除其他团队成员持续开发的提交，对团队开发会带来严重问题。当他们尝试与您的仓库同步时，它将看起来像项目历史的一大块突然消失。下面演示了当您尝试重置公共提交时会发生什么。该origin/master
分支是您当地master分支的中央仓库版本。

一旦您在重置后添加新的提交，Git会认为您的本地历史已经脱离了origin/master，并且同步存储库所需的合并提交可能会混淆和挫败您的团队。关键是，确保您在本地实验错误的时候使用git reset ，而不是发布的更改。如果您需要撤销公共提交，那么git revert命令更合适。

示例

取消暂存文件

在准备提交暂存快照时经常使用git reset命令。下一个示例假设您有两个文件hello.py和main.py已经添加到存储库。

# Edit both hello.py and main.py
# Stage everything in the current directory
git add .
# Realize that the changes in hello.py and main.py
# should be committed in different snapshots
# Unstage main.py
git reset main.py
# Commit only hello.py
git commit -m "Make some changes to hello.py"
# Commit main.py in a separate snapshot
git add main.py
git commit -m "Edit main.py"

您可以看到，git reset通过让您将无关的更改放到下一次提交，来帮助您建立保持高度集中的提交。

删除本地提交

下一个示例显示了更高级的用例。它演示了当您在一段时间内进行新实验时会发生什么，但决定在提交几个快照后完全将其删除。

# Create a new file called `foo.py` and add some code to it
# Commit it to the project history
git add foo.py
git commit -m "Start developing a crazy feature"
# Edit `foo.py` again and change some other tracked files, too
# Commit another snapshot
git commit -a -m "Continue my crazy feature"
# Decide to scrap the feature and remove the associated commits
git reset --hard HEAD~2

git reset HEAD~2命令将当前分支向后移动两次提交，从而有效地从项目历史记录中删除刚刚创建的两个快照。请记住，这种重置应仅用于未发布的提交。如果已将您的提交推送到公共仓库，则不要执行上述操作。

git clean

git clean命令从您的工作目录中删除未追踪的文件。这真的是一个方便的命令，通过git status看看哪些文件没有跟踪和然后手动删除它们。像一个普通的rm命令，git clean是不可逆的，所以一定要确保在运行它之前你真的想要删除未跟踪文件。

git clean命令通常与git reset –hard结合执行。请记住，重置仅影响已跟踪的文件，因此需要单独的命令来清理未跟踪的文件。综合这两个命令可让您将工作目录恢复到特定提交的确切状态。

用法

git clean -n

执行git clean的“无效运行”模式。这将显示哪些文件将被删除，而不会真实执行。

git clean -f

Remove untracked files from the current directory. The -f (force) flag is required unless the clean.requireForce configuration option is set to false (it’s true by default). This will not remove untracked folders or files specified by .gitignore.

从当前目录中删除未跟踪的文件。除非clean.requireForce的配置选项设置为false（默认情况下这是true），则需要-f（强制）标记。这不会删除未跟踪的文件夹或.gitignore指定的文件.

git clean -f <path>

删除未跟踪的文件，但将操作限制到指定的路径。

git clean -df

从当前目录中删除未跟踪的文件和未跟踪的目录。

git clean -xf

从当前目录以及Git通常忽略的任何文件中删除未跟踪的文件。

讨论

The git reset –hard and git clean -f commands are your best friends after you’ve made some embarrassing developments in your local repository and want to burn the evidence. Running both of them will make your working directory match the most recent commit, giving you a clean slate to work with.

The git clean command can also be useful for cleaning up the working directory after a build. For example, it can easily remove the .o and .exe binaries generated by a C compiler. This is occasionally a necessary step before packaging a project for release. The -x option is particularly convenient for this purpose.

Keep in mind that, along with git reset, git clean is one of the only Git commands that has the potential to permanently delete commits, so be careful with it. In fact, it’s so easy to lose important additions that the Git maintainers require the -f flag for even the most basic operations. This prevents you from accidentally deleting everything with a naive git clean call.

如果你在本地库开发过程中遇到问题，并要烧掉所有证据，git reset –hard和git clean -f命令你一定很喜欢。运行它们将使您的工作目录匹配最近的提交，给您一个干净的工作。

git clean命令也可用于清理构建后的工作目录。例如，它可以很容易地除去.o和.exe由C编译器生成的二进制文件。在包装项目发布之前，这偶尔是一个必要的步骤。该-x选项对于此目的特别方便。

请记住，与之一起的git reset，git clean是唯一可以永久删除提交的Git命令之一，所以要小心。事实上，它是如此容易失去了Git的维护者重要的补充需要的-f，即使是最基本的操作标志。这样可以防止您无意中使用git clean删除所有内容。

示例

以下示例清除了工作目录中的所有更改，包括已添加的新文件。它假设您已经提交了几个快照，并正在尝试一些新的开发。

# Edit some existing files
# Add some new files
# Realize you have no idea what you're doing
# Undo changes in tracked files
git reset --hard
# Remove untracked files
git clean -df

运行此重置/清除序列后，工作目录和暂存区域将与最近的提交完全相同，并且git status将报告一个干净的工作目录。你现在准备重新开始了。
请注意，与第二个示例不同git reset ，新文件_not _added到存储库。因此，他们不会受到影响git reset –hard，git clean被要求删除它们。