声明：这篇文章来源于廖雪峰老师的官方网站，我仅仅是作为学习之用

Git简介

Git是什么？

Git是目前世界上最先进的分布式版本控制系统。

什么是版本控制系统？

Git的诞生

很多人知道，Linus在1991年开源了Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。

Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那么Linux的代码是如何管理的呢？

事实上，在2002年以前，代码作者把源文件以diff的方式发给Linus，然后由Linus本人通过手工的方式合并代码。

当时也有免费的CVS、SVN这些免费的版本控制系统。但是Linus坚决的反对CVS、SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。

不过到了2002年，经过十年的发展，通过手工方式管理代码已经相当累人啦，而且社区的兄弟们也对这种方式表达了强烈的不满，于是Linus选择了一个商业的版本控制系统BitKeeper。BitKeeper的东家BitMover公司出于人道精神，授权Linux社区免费使用这个版本控制系统。

安定团结的局面在2005年被打破了，原因是开发Samba的Andrew试图破解BitKeeper的协议，被BitMover公司发现了，要收回Linux社区的免费使用权。

于是Linus花了两周的时间自己用C写了一个分布式的版本控制系统，这就是Git！一个月之内，Linux系统的源码就可以由Git管理了！

Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目提供免费Git存储，无数开源项目开始迁移至GitHub，包括JQuery，PHP，Ruby等等。

历史就是这么偶然，如果不是当年BitMover的决绝，那么现在我们可能就没有免费而且超级好用的Git了。

集中式VS分布式

Linus一直痛恨的CVS和SVN都是集中式的版本控制系统，而Git是分布式的版本控制系统，集中式和分布式的版本控制系统有什么分别呢？

先说集中式版本控制系统，版本库是放在中央服务器上的，而干活的时候，用的都是自己的电脑，就需要把版本先从中央服务器取得最新的版本，然后开始干活。干完活了，再把自己的劳动成果推给中央服务器。

集中式版本控制系统最大的问题就是必须联网才能工作。如果在局域网内还好说，带宽够大，速度够大。可如果在互联网上，遭遇网速慢的情况，可能提交一个10M的文件就需要5分钟。5分钟可以憋死一头牛啦。

分布式版本控制系统呢？它没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样你干活的时候就不需要联网啦，因为版本库就在本地啊。既然每个人的电脑上都有一个版本库，那么如何多人协作呢？比方说你在自己的电脑上修改了A文件，你的同事也在他的电脑上修改了A文件；你们只需要把修改的地方推给对方就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性不知道要高到哪里去。因为每个人电脑里都有完整的版本库，某个人的电脑坏了也不要紧，随便从其他人那里复制一个就可以。而集中式版本控制器的中央服务器要是出了问题，所有人都没法干活了。

在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在同一个局域网内，两台电脑互相访问不了；也可能你的同事今天生了病，根本就没开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改；没有它大家一样干活，只是交换修改不方便了而已。

当然Git优势不单是不必联网这么简单，后面我们还会看到Git极其强大的分支管理，把SVN等远远抛在了后面。

安装Git

在Linux上安装Git

如果你碰巧使用Debian或Ubuntu Linux，通过一条 sudo apt-get install git 就可以完成git的安装，非常之简单。

如果是其它Linux的版本，可以直接通过源码安装。先从Git官网下载源码，然后解压，依次输入: ./config, make, sudo make install 这几个命令就安装好了。

在Mac上安装Git

推荐一种简单的方法。直接从AppStore安装Xcode，Xcode中集成了Git，不过默认没有安装。你需要运行Xcode，选择菜单"Xcode"->"Preferences"，在弹出的窗口中找到“Downloads”，选择“Command Line Tools”，点“Install”就可以完成安装啦。

安装完成后，还需要进行最后一步设置，在命令行输入：

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

因为Git是分布式版本控制系统，所以每个机器都必须自报家门。

注意git config命令的--global参数。用了这个参数，表示你的这台机器上所有的Git仓库都会使用这个配置。当然你也可以对某个仓库指定不同的用户名和email地址。

创建版本库

版本库又叫仓库，英文名repository。版本库可以简单的理解成目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能追踪，以便在任何时刻都可以追踪历史，或者在将来的某个时候可以“还原”。

创建版本库非常简单，选择一个合适的地方，创建一个空目录：

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit

pwd命令用于显示当前目录。在我的Mac上，这个仓库位于/Users/michael/learngit。

第二步，通过git init命令把这个目录变成Git可以管理的仓库：

$ git init
Initialized empty Git repository in /Users/michael/learngit/.git

瞬间Git仓库就建好了，而且告诉你是一个空仓库，多出来的 .git目录是来跟踪管理版本库的，里面的文件不能手动修改，否则Git仓库会遭到破坏。

如果没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。

把文件添加到版本库

首先声明一点，所有的版本控制系统，其实只能跟踪文本文件的改变，比如txt文件，网页，所有的程序代码等等。Git也不例外。版本控制系统可以告诉你每次的改动，比如第5行增加了一个单词“Linux”，而在第8行删除了一个单词“Windows”等等...。而图片、视频这些二进制文件虽然也能由版本控制系统管理，但没法跟踪文件的改变，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但是到底改了啥，版本控制系统不知道，也没法知道。

不幸的是Microsoft的Word格式是二进制格式，因此版本控制系统无法跟踪Word的改变。如果要真正实用版本控制系统，就要以纯文本的方式编写文件。因为文本是有编码的，如中文有常用的GBK编码，日文有常用的Shift_JIS编码，如果没有历史遗留问题，强烈推荐使用标准的UTF-8编码，所有的语言使用同一种编码，既没有冲突，又被所有平台所支持。

另外注意千万不要用windows自带的记事本 编辑任何文本文件。原因是记事本保存UTF-8编码文件时会在每个文件开头添加0xefbbbf字符。

言归正传，现在编写一个readme.txt文件，内容如下：

Git is a version control system.
Git is free software.

这个文件一定要放在learngit目录下，放在别的地方Git找不到。

把一个文件放到Git仓库只需要两步：

第一步， 用git add告诉git，把文件添加到仓库

 $ git add readme.txt

第二步，用git commit告诉Git，把文件提交到仓库

$ git commit -m "wrote a readme file"
[master (root -commit) cb926e7] wrote a readme file 1 file changed, 2 insertions(+)
create mode 10064 readme.txt

简单解释一下git commit命令，-m后面输入的是本次提交的说明，这样你就能从历史纪录中方便的查找改动纪录。

时光穿梭机

我们已经添加并提交了一个readme.txt文件，现在我们修改readme.txt，改成如下内容：

Git is a distributed version control system.
Git is free software.

现在运行git status 命令。git status命令可以让我们看到仓库的状态，上面的命令告诉我们，readme.txt被修改过了。并且告诉我们后序的处理方案。git add将修改添加到仓库，git checkout丢弃修改。

git status只能告诉我们修改了哪些文件，但具体修改了文件的哪些内容就需要用git diff这个命令了。

提交修改

提交修改和提交新文件是一样的两个步骤。

第一步 是git add

$ git add readme.txt

在执行第二步git commit之前，我们用git status查看仓库状态。git commit命令告诉我们后序的操作，看来Git还是很友好的。

$ git commit -m "add distributed"

提交后，我们再用git status命令查看仓库状态。

$ git status
# On branch master
nothing to commit (working directory clean)

Git 告诉我们当前没有需要提交的修改，工作目录是干净的。

小结

• 随时掌握工作区状态，使用git status命令
• 用git diff可以查看具体的修改内容

版本回退

现在我们再次修改readme.txt文件

Git is a distributed version control system.
Git is free software distributed under the GPL.

然后提交

$ git add readme.txt
$ git commit -m "append GPL"

像这样可以不断修改不断提交到版本库，这样Git就能跟踪文本的改变。当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快找在Git中成为commit。一旦你把文件改乱了，或者误删了文件，就可以从最近的一个commit恢复，然后继续工作。这样就不会把前几个月的工作成果丢失。

现在我们的Git仓库中有三个版本啦。

版本1: wrote a readme file

版本2: add distributed

版本3: append GPL

查看历史纪录

版本控制系统有某个命令可以查看历史纪录，在Git中git log就是也。

$ git log
commit 8ae8b878c335c5ae8ed381460345d2b03e8e3c6e
Author: zhangxiaojun <adam.zhang@ydx.hk>
Date:   Fri Mar 11 00:01:24 2016 +0800
    
    append GPL

commit 3eb82b8e2c94fbc5fdb0ca248fa7c15789df922c
Author: zhangxiaojun <adam.zhang@ydx.hk>
Date:   Thu Mar 10 23:59:53 2016 +0800

    add distributed

commit e9da25c20a570b2f6280d3bb47a5e0d3935a5a8b
Author: zhangxiaojun <adam.zhang@ydx.hk>
Date:   Thu Mar 10 23:58:00 2016 +0800

    wrote a readme file

git log可以显示从最近到最远的提交日至。如果嫌弃输出太多的信息，可以加上--pretty=oneline参数：

$ git log --pretty=oneline
8ae8b878c335c5ae8ed381460345d2b03e8e3c6e append GPL
3eb82b8e2c94fbc5fdb0ca248fa7c15789df922c add distributed
e9da25c20a570b2f6280d3bb47a5e0d3935a5a8b wrote a readme file

版本号

一大串类似8ae8b87...d2b03ec6e的数字是commit id（版本号）。和SVN不一样，Git的commit id不是1、2、3...的递增数字，而是由SHA1计算出来的一个非常大的数字，用十六进制表示。为什么commit id需要一串这么大的数字来表示呢？因为Git是分布式控制系统，后面我们还要研究多个人在同一个版本库工作，如果大家都用1、2、3...作为版本号，那么肯定会引发冲突。

每提交一个版本，实际Git就会把它们自动串成一条时间线。如果使用可视化工具查看Git历史，就可以清楚地看到提交历史的时间线。

时光穿梭机

首先Git必须要知道当前版本是哪个版本，在Git中用HEAD表示当前版本，也就是最新的commit id，上一个版本用HEAD^表示，上上个版本是HEAD^^,再往上一个版本就是HEARD~3。

现在我们从当前版本“append GPL”退回到上一个版本“add distributed”，就可以使用git reset命令：

$ git reset --hard HEAD^
HEAD is now at 3eb82b8 add distributed

最新版本"append GPL"已经不见了！好比从21世纪坐时光穿梭机回到了19世纪，现在又想回去了，肿么办？

办法还是有的，只要刚才的命令行窗口没有关，可以往上找到"append GPL"对应的commit id,于是就可以回到未来的某个版本

$ git reset --hard 8ae8
HEAD is now at 8ae8b87 append GPL

Git的版本回退速度是非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本时，Git仅仅是把HEAD指向append GPL。然后顺便把工作区的文件更新了，所以你让HEAD指向哪个版本号，你就把当前版本定位在了哪里。

现在你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想要恢复到最新的版本怎么办？找不到新版本的commit id怎么办？

在Git中总是有后悔药可医吃的。Git提供了一个命令git reflog来纪录你的每一次命令：

$ git reflog
e9da25c HEAD@{0}: reset: moving to HEAD^^
8ae8b87 HEAD@{1}: reset: moving to 8ae8
3eb82b8 HEAD@{2}: reset: moving to HEAD^
8ae8b87 HEAD@{3}: commit: append GPL
3eb82b8 HEAD@{4}: commit: add distributed
e9da25c HEAD@{5}: commit (initial): wrote a readme file

长出一口气，第5行显示 append GPL的commit id是 8ae8b87。现在我们可以乘坐时光机回到未来了。

小结

小结一下

• HEAD指向的版本就是当前版本，Git允许我们在版本之间时光穿梭，使用命令git reset --hard commit_id。
• 穿梭前，用git log查看提交历史纪录，以便确认要退到哪个版本。
• 要重返未来，用git reflog查看命令历史，以便确定回到未来的哪个版本。

远程仓库

用过集中式版本管理系统的同学会说，前面这些功能SVN里早就有了，没有看出Git有什么特别的地方。

没错，如果只是一个仓库管理文件历史，Git和SVN真的没啥区别。为了保证你学习Git物超所值，将来绝对不会后悔，我们开始介绍Git的杀手级功能之一：远程仓库。

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。

你肯定会想，至少需要两台机器才能玩远程库不是？但是直有一台电脑怎么玩？

• 其实一台电脑也可以玩，只要仓库在不同的目录下，但是在世纪开发中这种方式完全没有意思。
• 实际开发时，需要自己搭建一台运行Git的服务器。
• 有一个叫GitHub的神奇网站，这个网站是专门提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。

我们现在就将Git仓库托管到GitHub上，来看一下具体的步骤。

第一步，创建 SSH KEY。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果有了可以直接进行下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH KEY：

$ ssh-keygen -t rsa -C "youremail@example.com"

需要把邮件地址换成自己的邮件地址，然后一路回车，使用默认值即可，也无需设置密码。

如果一切顺利会在用户主目录找到.ssh目录里面有id_rsa和id_rsa.pub这两个文件。这两个就是SSH的秘钥对，id_rsa是私钥，id_rsa.pub是公钥，公钥可以放心的告诉别人。

第二步，登录GitHub，打开“Account settings”，“SSH Keys”页面。然后点击“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件内容，通俗的讲就是把公钥告诉GitHub。

为什么GitHub需要知道你的SSH Key呢？因为GitHub需要认证你推送的提交确实是你推送的，而不是别人冒充的。而Git支持SSH协议，所以GitHub只要知道了你的公钥，就可以确定只有你自己才能推送。

当然GitHub允许你添加多个key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交。只要把每台电脑的key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但是只有你自己才能修改）。所以不要把敏感信息放进去。
如果你不想让别人看到Git仓库，有两个办法。一个是交点保护费把公开的仓库变成私有的，这样别人就看不到了。另一个办法是自己动手搭建一个Git服务器。

小结

有了Git远程仓库，再也不用担心自己的硬盘了，代码的存放也会有管家替我管理啦，另外我也可以把纯文本的学习笔记让GitHub替我托管啦。

添加远程仓库

现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样GitHub上的仓库即可以作为备份，又可以让其他人通过仓库来协作，真是一举多得。

首先登录GitHub，然后点击右上角的加号“Create a new rep”按钮，创建一个新的仓库：

在Repository name 中填入learngit，其它保持默认设置，点击"Create repository"按钮，就成功创建了一个新的Git仓库：

hah

现在我们要做的是将本地仓库与远程仓库关联，根据GitHub的提示，在本地的learngit仓库运行命令：

$ git remote add origin git@github.com:honeywolf/learngit.git

将honeywolf替换成自己的GitHub账户名，否则你在本地关联的是我的远程仓库，关联没有问题，但是以后推送代码是推送不了的，因为你的SSH Key公钥不再我的帐户列表中。

添加后，远程仓库的名字就是origin，这事Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

下一步就是把本地的内容推送到远程库：

$ git push -u origin master
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 270 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:honeywolf/learngit.git
* [new branch]      master -> master
Branch master set up to track remote branch master from origin.

把本地内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时可以简化命令。

从现在起，只要本地作了提交，就可以通过命令：

$ git push origin master

把本地master分支的最新修改推送至GitHub，现在，你就真正拥有了分布式版本库。

创建与合并分支

在版本回退里，我们已经知道，每次提交，Git会把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git中这个分支叫做主分支，即master分支。HEAD严格来讲并不是指向提交(commit_id)，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点。

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建一个新的分支dev的时候，Git新建了一个指针叫做dev，指向master相同的提交，这样一个新的分支就诞生了。再把HEAD指向dev，就表示当前分支在dev上。这样看来Git创建分支的速度很迅猛，因为除了增加一个指针dev，改变HEAD的指向，工作区的文件都没有发生变化。

不过从现在开始，对工作区的修改和提交就是针对dev分支啦，比如新提交一次后，dev指针往前移动了一步，而master指针是不变的。

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并分支呢？最简单的办法，就是直接把master指向dev的当前提交，就完成了合并。所以Git分支的合并也很迅捷，工作区的内容也不会发生改变。

合并完成以后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支。

下面开始实战。

首先，我们创建一个dev分支，然后切换到dev分支。

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条指令

$ git branch dev
$ git checkout dev
Switched to a new branch 'dev'

git branch命令会列出所有分支，当前分支前面有个*号：

$ git branch
* dev
master

然后我们在dev上可以做正常的提交，比如对readme.txt的修改，加上一行：

creating a new branch is quick

然后提交

$ git commit -a -m "branch test"
[dev e96c626] branch test
1 file changed, 2 insertions(+)

现在dev的工作完成了，我们就可以切换回master分支。

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

现在我们切回master分支后，再查看readme.txt文件，刚才添加的内容不见了！因为那个提交实在dev分支上，而master分支此刻的提交点并没有发生变化。
现在，我们把dev的工作成果合并到master分支：

$ git merge dev -m "merge dev"
Updating e9da25c..e96c626
Fast-forward 
readme.txt | 2 ++
1 file changed, 2 insertions(+)

git merge命令用于合并指定分支到当前分支。合并后，再查看 readme.txt文件内容，就可以看到，和dev分支最后提交的是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并的速度非常的快。

当然并不是每次合并都能使用Fast-forward模式，后面我们会讲道其他方式的合并。

合并完成后，就可以放心地删除dev分支了。

$ git branch -d dev
Deleted branch dev (was e96c626).

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删除分支，这和直接在master分支上工作效果是一样的，但过程更安全。

小结

Git鼓励大量使用分支：
查看分支 git branch

创建分支 git branch <name>

切换分支 git checkout <name>

创建+切换分支 git checkout -b <name>

合并到当前分支 git merge <name>

删除分支 git branch -d <name>

解决冲突

人生不如意事有九八，合并分支往往也不是一帆分顺的。

准备新的feature1分支，继续我们的新分支开发：

$ git checkout -b feature1
Switched to a new branch 'feature1'

修改readme.txt最后一行，改为：

$ git add readme.txt 
$ git commit -m "AND simple"
[feature1 8974d1b] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)

Git 会自动提示我们当前的master分支比远程的master分支要超前一个提交。

在master分支上把readme.txt最后一行改为：

Creating a new branch is quick & simple.

提交：

$ git add readme.txt 
$ git commit -m "& simple"
[master e4a1309] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

现在master分支和feature1分支各自都分别有新的提交：

在这种情况下Git无法执行快速合并，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

$  git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突然后再提交。git status也可以告诉我们冲突的文件：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
You have unmerged paths.
(fix conflicts and run "git commit")

Unmerged paths:
(use "git add <file>..." to mark resolution)

both modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

我们可以查看readme.txt的内容：

Git is a version control system.
Git is a free software.
<<<<<<< HEAD
Create a new branch is quick & simple.
=======
Create a new branch is quick AND simple.
>>>>>>> feature1

Git使用<<<<<<<，=======，>>>>>>>标记出不同的内容，我们修改成如下后保存。

Create a new branch is quick and simple.

再提交：

$ git add readme.txt 
$ git commit -m "conflic fixed"
[master 4f8be33] conflic fixed

用带参数的git log也可以看到分支的合并情况：

$ git log --graph --pretty=oneline --abbrev
*   4f8be331c4a0972055f295cf8b8c4e7cec15e8d3 conflic fixed
|\  
| * 8974d1bf72c971d6904568f5ada712559a13a1b2 AND simple
* | e4a1309271c343c844caaa4217ca8724024b8642 & simple
|/  
* e96c626c9adf06390a936c51e3de6723e1d2e3b3 branch test
* e9da25c20a570b2f6280d3bb47a5e0d3935a5a8b wrote a readme file

最后删除feature1分支:

$ git branch -d feature1
Deleted branch feature1 (was 8974d1b).

工作完成。

小结

当Git无法自动合并分支时，就必须首先要解决冲突。解决冲突后，再提交，合并完成。
用git log --graph命令可以看到分支合并图。

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但在这种模式下，删除分支后，会丢掉分支信息。

如果强制禁用Fast forward模式，Git会在merger时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge

首先我们仍然要创建并切换dev分支

修改readme.txt文件，并提交一个新的commit：

我们切回master

准备合并dev分支，请注意--no-f参数，表示禁止使用Fast forward:

$ git merge --no-f -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写了进去。

合并后我们用git log查看分支历史：

$ git log --graph --pretty=oneline
*   9e2804ba5091cf25825479b4483d98d1767f31b0 merge with no-ff
|\  
| * 41b696e22b98cd19baa45824a355656658a1d06d add merge
|/  
*   4f8be331c4a0972055f295cf8b8c4e7cec15e8d3 conflic fixed
|\  
| * 8974d1bf72c971d6904568f5ada712559a13a1b2 AND simple
* | e4a1309271c343c844caaa4217ca8724024b8642 & simple
|/  
* e96c626c9adf06390a936c51e3de6723e1d2e3b3 branch test
* e9da25c20a570b2f6280d3bb47a5e0d3935a5a8b wrote a readme file

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先：master分支应该是非常稳定的，也就是仅仅用来发布新版本，平时不能在上面干活；

那在哪里干活呢？干活都在dev分支上，也就是说dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上。在master上发布1.0版本。

你和你的小伙伴每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上--no-ff参数就可以以普通模式合并，合并后的历史分支，能看出来作了哪些合并，而Fast forward合并就看不出来曾经做过合并。

Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此强大。所以每个bug都可以通过一个临时分支修复，修复后合并分支，然后将临时分支删除。

当你接到一个修复代号为101的bug任务时，很自然的，你想创建一个分支issue-101来修复它。但是，先等一等，当前正在dev上进行的工作还没提交呢。

$ git status
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

new file:   hello.py

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working  directory)

modified:   readme.txt

并不是你不想提交，而是工作还没有完成，还没法提交，预计完成还需一天时间。但是，必须在两个小时之内修复改bug，怎么办？

Git考虑的很周到，为我们提供了git stash功能，可以把工作区现场“存储”起来，等以后恢复现场后继续工作。

$ git stash
Saved working directory and index state WIP on dev: 41b696e add merge
HEAD is now at 41b696e add merge

现在用git status来查看情况，工作区就是干净的，除非有没有被Git管理的文件。因此你就可以放心大胆的地创建新的分支来修复bug。

首先要确定在哪个分支上修复bug，假定需要在master上修复，就从master创建临时分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

现在修复bug，然后提交:

$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 20f6aa2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完，切换到master分支，完成合并，删除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)

$ git merge --no-ff -m "merge fix bug 101" issue-101
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

$ git branch -d issue-101
Deleted branch issue-101 (was 20f6aa2).

太棒了，原计划两个小时的bug修复只花费了5分钟！现在是时候回到dev分支干活啦。

$ git checkout dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working directory clean

工作区是干净的，刚才的工作现场到哪里去了？用git stash list查看

$ git stash list
stash@{0}: WIP on dev: 41b696e add merge

工作现场还在，Git把工作现场存储到了某个地方，但是需要恢复一下，有两个办法:

一是用git stash apply恢复，但是恢复后，stash内容并不清楚，你需要用git stash drop来删除；

另一种方法是用 git stash pop,恢复的同时把stash的内容也删了：

$ git stash pop
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

new file:   hello.py

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working  directory)

modified:   readme.txt

Dropped refs/stash@{0} (8ba1ca0c4d887d79faba741dca8ff37fa5612fb6)

再用git stash list查看，就看不到任何stash的内容了：

$ git stash list

你可以多次stash，恢复的时候先用git stash list查看，然后恢复指定的stash，用命令：

git stash apply stash@{1}

小结

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除

当手头工作没有完成时，我们用git stash将工作区缓存，然后去修复bug。bug改完后，再git stash pop。

Feature分支

软件开发过程汇总，总有无穷尽的新功能要不断添加进来。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了。所以每添加一个新功能最好添加一个新的feature分支，在上面开发新功能。完成后，合并，删除该feature分支。

现在你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。

于是准备开发

$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'

5分钟后，开发完毕：

$ git status
On branch feature-vulcan
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

new file:   vulcan.py
$ git commit -m "add feature vulcan"
[feature-vulcan 8f9c087] add feature vulcan
1 file changed, 1 insertion(+)
create mode 100644 vulcan.py

切回dev，准备合并：

$ git checkout dev
Switched to branch 'dev'

一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。
但是，就在此时，接到上级命令，因经费不足，新功能必须取消！

虽然白干了，但是这个分支还是必须就地销毁：

$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-  vulcan'.

Git提示，该分支未完全merge，还不能删除，如果要强行删除，需要使用git branch -D feature- vulcan命令：

现在我们强行删除：

$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 8f9c087).

小结

开发一个新的feature，最好创建一个新的分支；

如果要丢弃一个没有被合并过的分支，可以通过 git branch -D feature-vulcan强行删除。

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程仓库的信息用git remote

$ git remote
origin

或者用git remote -v显示更详细的信息：

$ git remote -v
origin git@github.com:hoenywolf/learngit.git
 (frtch)
origin git@github.com:hoenywolf/learngit.git
 (push)

上面显示了可以抓取和推送的origin地址。如果没有推送权限就看不到push地址。

推送分支

推送分支，就是把分支上的所有本地数据提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的分支上：

$ git push origin master

如果要推送其他分支，比如dev，就改成：

$ git push origin dev

但是，并不是一定要把本地分支往远程推送，那么哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要时刻与远程仓库同步；
• dev是开发分支，团队所有的成员都要在上面工作，所以也需要与远程同步；
• bug分支只用于在本地修复bug，就没必要推送到远程了，除非老板要看看你每周修复了几个bug
• feature分支是否推送到远程取决于你是否和你的伙伴合作在上面开发。

总之在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

抓取分支

多人协作时，大家都会往master分支和dev分支上推送各自的修改。

现在模拟一个你的小伙伴，可 以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆:

$ git clone git@github.com:honeywolf/learngit.git

当你的小伙伴从远程仓库clone时，默认情况下，你的小伙伴只能看到本地master分支。

$ git branch
* master

现在，你的小伙伴要在dev分支上开发，就必须创建远程orgin的dev分支到本地，于是他用这个命令创建本地分支:

$ git checkout -b dev origin/dev

现在，他就可以在dev分支上继续修改，然后时不时地不断把dev分支push到远程：

$ git commit -m "add /usr/bin/env"
....
$ git push origin dev
....

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：

$ git push origin dev
To git@github.com:honeywolf/learngit.git
! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to 'git@github.com:honeywolf/learngit.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用 git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

$ git pull
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 8 (delta 0), reused 8 (delta 0), pack-reused 0
Unpacking objects: 100% (8/8), done.
From github.com:honeywolf/learngit
a947c9b..2f95e78  dev        -> origin/dev
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details

git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=origin/<branch> dev

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

$ git branch --set-upstream-to=origin/dev dev

再pull：

$ git pull

这回git pull成功，但是合并有冲突，需要手动解决，解决的办法和分支管理中解决冲突完全一样。解决后，然后提交，再push：

$ git commit -m "merge & fix hello.py"
...
$ git push origin dev
...

因此多人协作的工作模式通常是这样的：

1. 首先，自己试图用 git push origin branch-name推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要用git pull试图合并
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin brach-name推送就能成功。

如果git pull提示"no tracking information"，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

小结

• 查看远程库信息，使用git remote -v；
• 本地新建的分支如果不推送到远程，对其他人就是不可见的；
• 从本地推送分支，使用git push origin branch-name,如果推送失败先用git pull抓取远程的最新提交；
• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致；
• 建立本地分支和远程分支的关联，使用git branch --set-upstream-to=origin/<branch-name> <branch-name>
• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

标签管理

发布一个版本时，我们通常在版本库中打一个标签，这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取这个标签的版本，就是把那个打标签时刻的历史版本取出来。所以标签也是版本库的一个快照。

Git标签虽然是版本库的快照，但其实它就是指向某个commit 指针（跟分支很像对不对？但是分支是可以移动的，标签不可以移动）所以，创建和删除标签都是瞬间完成的。

创建标签

在Git中打标签非常简单，首先，切换到需要打标签的分支上：

$ git branch 
* dev
master
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

然后敲命令git tag <name>就可以打一个新标签：

$ git tag v1.0

可以用git tag命令查看所有的标签

$ git tag
v1.0

默认的标签都是打在最新的commit提交上的。有时候，会忘记打标签。比如现在已经周五了，但应该在周一打的标签没有打，该怎么办呢？

方法是找到历史提交的 commit id,然后打上就可以了：

$ git log --pretty=oneline --abbrev-commit
4e90863 merge fix bug 101
20f6aa2 fix bug 101
9e2804b merge with no-ff
41b696e add merge
4f8be33 conflic fixed
e4a1309 & simple
8974d1b AND simple
e96c626 branch test
e9da25c wrote a readme file

比方说要对add merge这次提交打标签，它对应的commit id 是41b696e，敲入命令

$ git tag v0.9 41b696e
$ git tag
v0.9
v1.0

注意标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：

$ git show v0.9
commit 41b696e22b98cd19baa45824a355656658a1d06d
Author: honeywolf <adam.h@gmail.com>
Date:   Fri Mar 11 23:42:57 2016 +0800

add merge
...

可以看到，v0.9确实打在add merge这次提交上。
还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

$ git tag -a v0.1 -m "version 0.1 released" 20f6aa220

用命令git show <tagname>可以看到说明文字

$ git show v0.1
tag v0.1
Tagger: honeywolf <adam.h@gmail.com>
Date:   Sat Mar 12 14:56:11 2016 +0800

version 0.1 released

commit 20f6aa22033491f033d54efe1088fc04e7fbff38
Author: honeywolf <adam.h@gmail.com>
Date:   Sat Mar 12 00:16:50 2016 +0800

    fix bug 101

还可以通过-s用私钥签名一个标签：

$ git tag -s v0.2 -m "signed version 0.2 released" 4e90863dc

签名采用PGP签名，因此，必须首先安装gpg（GnuPG），如果没有找到gpg，或者没有gpg密钥对，就会报错：

error: cannot run gpg: No such file or directory
error: could not run gpg.
error: unable to sign the tag

如果报错，请参考GnuPG

小结

• 命令git tag <name>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
• git tag -a <tagname> -m "balabalabala..."可以指定标签信息；
• git tag -s <tagname> -m "balabalabala..."可以用PGP签名标签；
• 命令git tag可以查看所有标签。

操作标签

如果标签打错了，可以删除：

$ git tag -d v0.1
Deleted tag 'v0.1' (was c9e4c38)

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。

如果要推送到远程，使用命令git push origin <tagname>：

$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:honeywolf/learngit.git
* [new tag]         v1.0 -> v1.0

或者一次性推送全部尚未推送到远程的本地标签：

git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:honeywolf/learngit.git
* [new tag]         v0.9 -> v0.9

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：

git tag -d v0.9
Deleted tag 'v0.9' (was 41b696e)

然后从远程删除。删除命令也是push，但是格式如下：

$ git push origin :refs/tags/v0.9
To git@github.com:honeywolf/learngit.git
- [deleted]         v0.9

要看看是否真的从远程删除了标签，可以登录GitHub查看。

小结

• 命令git push origin <tagname>可以推送一个本地标签
• 命令git push origin --tags可以推送全部未推送过的本地标签；
• 命令git tag -d <tagname>可以删除一个本地标签；
• 命令git push origin :refs/tags/<tagname>可以删除一个远程标签。

使用GitHub

我们一直用GitHub作为免费的仓库，如果是个人开源项目，放到GitHub上是完全没有问题的。其实GitHub还是一个开源协作社区，通过GitHub，即可以让别人参与你的 开源项目，也可以参与别人的开源项目。

在GitHub出现以前，开源项目开源容易，但让广大人民群众参与进来比较困难，因为要参与，就要提交代码，而给每个想提交代码的群众都开一个账号那是不现实的，因此，群众也仅限于报个bug，即使能改掉bug，也只能把diff文件用邮件发过去，很不方便。

但是在GitHub上，利用Git及其强大的克隆和分支功能，广大人民群众真正可以第一次自由参与各种开源项目了。

如何参与一个开源项目呢？比如人气极高的booststrap项目，这是一个非常强大的CSS框架，你可以访问它的项目主页https://github.com/twbs/bootstrap，点击"Fork"就在自己的帐号下克隆了一个bootstrap仓库，然后，从自己的帐号下clone：

git clone git@github.com:honeywolf/bootstrap.git

一定要从自己的帐号下clone仓库，这样你才能推送修改。如果从bootstrap作者的仓库地址git@github.com:twbs/bootstrap.git克隆，因为没有权限，你将不能推送修改。

如果你希望修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。

如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。

小结

• 在GitHub上，可以任意Fork开源仓库；
• 自己拥有Fork后的仓库的读写权限；
• 可以推送pull request给官方仓库来贡献代码。

自定义Git

在安装Git一节中，我们已经配置了user.name和user.email，实际上，Git还有很多可配置项。比如，让Git显示颜色，会让命令输出看起来更醒目：

$ git status
On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

modified:   readme.txt

文件名就会标上颜色。我们后序还会介绍如何更好的配置Git，以便让你的工作更高效。

忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但是又不想提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，GitHub已经为我们准备了各种配置文件，只要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore

忽略文件的原则是：

1. 忽略操作系统自动生成的文件，比如缩略图等；
2. 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
3. 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

举个例子：
假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

# My configurations:
db.ini
deploy_key_rsa

最后一步就是把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。

使用Windows的童鞋注意了，如果你在资源管理器里新建一个.gitignore文件，它会非常弱智地提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

OC语言的.gitignore

# Xcode
#
# gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore

## Build generated
build/
DerivedData/

## Various settings
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata/

## Other
*.moved-aside
*.xcuserstate

## Obj-C/Swift specific
*.hmap
*.ipa

# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
# Pods/

# Carthage
#
# Add this line if you want to avoid checking in source code from Carthage dependencies.
# Carthage/Checkouts

Carthage/Build

# fastlane
#
# It is recommended to not store the screenshots in the git repo. Instead, use fastlane to re-generate the 
# screenshots whenever they are needed.
# For more information about the recommended setup visit:
# https://github.com/fastlane/fastlane/blob/master/docs/Gitignore.md

fastlane/report.xml
fastlane/screenshots

小结

• 忽略某些文件时，需要编写.gitignore；
• .gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！

配置别名

有没有经常敲错命令？比如git status? status这个单词真心不好记。

如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。

我们只需要敲一行代码，告诉Git，以后st就是status:

$ git config --global alias.st status

当然还有别的命令可以简写，很多人都用co表示checkout，ci表示commit，br表示branch：

$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch

--global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。

在撤销修改一节中，我们知道，命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名：

$ git config --global alias.unstage 'reset HEAD'

配置一个git last，让其显示最后一次提交信息：

$ git config --global alias.last 'log -1'

甚至还有人丧心病狂地把lg配置成了：

    git config --global alias.lg "log --color --graph --    pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)  %C(bold blue)<%an>%Creset' --abbrev-commit"

配置文件

配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。

配置文件放哪了？每个仓库的Git配置文件都放在.git/config文件中：

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
url = git@github.com:honeywolf/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[branch "dev"]
    remote = origin
    merge = refs/heads/dev

别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。

而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：

$ cat .gitconfig 
[filter "lfs"]
    clean = git-lfs clean %f
    smudge = git-lfs smudge %f
    required = true
[user]
    name = honeywolf
email = adam.honey@ydx.hk
[color]
    ui = true
[alias]
    st = status
    co = checkout
    ci = commit
    br = branch
    unstage = reset HEAD
    last = log -1
    lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。

小结

给Git配置好别名，就可以输入命令时偷个懒。我们鼓励偷懒 。