Git使用

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

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 GPLcommit id8ae8b87。现在我们可以乘坐时光机回到未来了。

小结

小结一下

  • 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_rsaid_rsa.pub这两个文件,如果有了可以直接进行下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH KEY:

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

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

如果一切顺利会在用户主目录找到.ssh目录里面有id_rsaid_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
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),而是指向mastermaster才是指向提交的,所以,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分支上开发,就必须创建远程orgindev分支到本地,于是他用这个命令创建本地分支:

$ 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分支的链接,根据提示,设置devorigin/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.nameuser.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.pyodist等文件或目录:

# 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配置好别名,就可以输入命令时偷个懒。我们鼓励偷懒 。

推荐阅读更多精彩内容