Git教程by廖雪峰


Git教程 史上最浅显易懂的Git教程! 为什么要编写这个教程?因为我在学习Git的过程中,买过书,也在⺴上Google了⼀堆Git 相关的⽂章和教程,但令⼈失望的是,这些教程不是难 得令⼈发指,就是简单得⼀笔带 过,或者,只⽀离破碎地介绍Git的某⼏个命令,还有直接从Git⼿册粘贴帮助⽂档的,总 之,初学者很难找到⼀个由浅⼊深, 学完后能⽴刻上⼿的Git教程。 既然号称史上最浅显易懂的Git教程,那这个教程有什么让你怦然⼼动的特点呢? ⾸先,本教程绝对⾯向初学者,没有接触过版本控制概念的读者也可以轻松⼊⻔,不必担⼼ 起步难度; 其次,本教程实⽤性超强,边学边练,⼀点也不觉得枯燥。⽽且,你所学的Git命令是“充 分且必要”的,掌握了这些东⻄,你就可以通过Git轻松地完成你的⼯作。 ⽂字+图⽚还看不明⽩?有视频!!! 本教程只会让你成为Git⽤户,不会让你成为Git专家。很多Git命令只有那些专家才明⽩ (事实上我也不明⽩,因为我不是Git专家),但我保证 这些命令可能你⼀辈⼦都不会⽤ 到。既然Git是⼀个⼯具,就没必要把时间浪费在那些“⾼级”但⼏乎永远不会⽤到的命令 上。⼀旦你真的⾮⽤不可了,到时候再 ⾃⾏Google或者请教专家也未迟。 如果你是⼀个开发⼈员,想⽤上这个世界上⺫前最先进的分布式版本控制系统,那么,赶快 开始学习吧! 关于作者 廖雪峰 ,⼗年软件开发经验,业余产品经理,精通Java/Python/Ruby/Visual Basic/ Objective C等,对开源框架有深⼊研究,著有《Spring 2.0核⼼技术与最佳实践》⼀书, 多个业余开源项⺫托管在 GitHub,欢迎微博交流:@廖雪峰。 Git教程 By 廖雪峰 整理、排版: numbbbbb Git简介 ! 5 Git的诞⽣ ! 7 集中式 vs分布式 ! 8 安装 Git! 10 在 Linux上安装 Git! 11 在 Mac OS X上安装 Git! 12 在 Windows上安装 Git! 13 创建版本库 ! 14 把⽂件添加到版本库 ! 14 ⼩结 ! 16 时光机穿梭 ! 17 ⼩结 ! 18 版本回退 ! 19 ⼩结 ! 22 ⼯作区和暂存区 ! 24 ⼩结 ! 27 管理修改 ! 28 ⼩结 ! 29 撤销修改 ! 30 ⼩结 ! 32 删除⽂件 ! 33 远程仓库 ! 35 ⼩结 ! 37 添加远程库 ! 38 ⼩结 ! 40 从远程库克隆 ! 41 ⼩结 ! 42 Git教程 By 廖雪峰 整理、排版: numbbbbb 分⽀管理 ! 43 创建与合并分⽀ ! 44 ⼩结 ! 47 解决冲突 ! 49 ⼩结 ! 51 分⽀管理策略 ! 53 分⽀策略 ! 54 ⼩结 ! 54 Bug分⽀ ! 55 ⼩结 ! 57 Feature分⽀ ! 58 ⼩结 ! 59 多⼈协作 ! 60 ⼩结 ! 63 标签管理 ! 64 创建标签 ! 65 ⼩结 ! 67 操作标签 ! 68 ⼩结 ! 68 使⽤ GitHub! 69 ⼩结 ! 69 ⾃定义 Git! 70 忽略特殊⽂件 ! 71 ⼩结 ! 72 配置别名 ! 73 ⼩结 ! 74 搭建 Git服务器 ! 75 Git教程 By 廖雪峰 整理、排版: numbbbbb 期末总结 ! 77 Git教程 By 廖雪峰 整理、排版: numbbbbb Git简介 Git是什么? Git是⺫前世界上最先进的分布式版本控制系统(没有之⼀)。 Git有什么特点?简单来说就是:⾼端⼤⽓上档次! 那什么是版本控制系统? 如果你⽤Microsoft Word写过⻓篇⼤论,那你⼀定有这样的经历: 想删除⼀个段落,⼜怕将来想恢复找不回来怎么办?有办法,先把当前⽂件“另存 为……”⼀个新的Word⽂件,再接着改,改到⼀定程度,再“另存为……”⼀个新⽂件, 这样⼀直改下去,最后你的Word⽂档变成了这样: 过了⼀周,你想找回被删除的⽂字,但是已经记不清删除前保存在哪个⽂件⾥了,只好⼀个 ⼀个⽂件去找,真⿇烦。 看着⼀堆乱七⼋糟的⽂件,想保留最新的⼀个,然后把其他的删掉,⼜怕哪天会⽤上,还不 敢删,真郁闷。 更要命的是,有些部分需要你的财务同事帮助填写,于是你把⽂件Copy到U盘⾥给她(也 可能通过Email发送⼀份给她),然后,你继续修改 Word⽂件。⼀天后,同事再把Word⽂ 件传给你,此时,你必须想想,发给她之后到你收到她的⽂件期间,你作了哪些改动,得把 你的改动和她的部分合并, 真困难。 于是你想,如果有⼀个软件,不但能⾃动帮我记录每次⽂件的改动,还可以让同事协作编 辑,这样就不⽤⾃⼰管理⼀堆类似的⽂件了,也不需要把⽂件传来传去。如果想查看某次改 动,只需要在软件⾥瞄⼀眼就可以,岂不是很⽅便? 这个软件⽤起来就应该像这个样⼦,能记录每次⽂件的改动: Git教程 By 廖雪峰 整理、排版: numbbbbb 版本 ⽤户 说明 ⽇期 1 张三 删除了软件服务条款5 7/12 10:38 2 张三 增加了License人数限制 7/12 18:09 3 李四 财务部门调整了合同金额 7/13 9:51 4 张三 延长了免费升级周期 7/14 15:17 这样,你就结束了⼿动管理多个“版本”的史前时代,进⼊到版本控制的20世纪。 Git教程 By 廖雪峰 整理、排版: numbbbbb Git的诞⽣ 很多⼈都知道,Linus在1991年创建了开源的Linux,从此,Linux系统不断发展,已经成为 最⼤的服务器系统软件了。 Linus虽然创建了Linux,但Linux的壮⼤是靠全世界热⼼的志愿者参与的,这么多⼈在世界各 地为Linux编写代码,那Linux的代码是如何管理的呢? 事实是,在2002年以前,世界各地的志愿者把源代码⽂件通过diff的⽅式发给Linus,然后由 Linus本⼈通过⼿⼯⽅式合并代码! 你也许会想,为什么Linus不把Linux代码放到版本控制系统⾥呢?不是有CVS、SVN这些免 费的版本控制系统吗?因为Linus坚定地反对 CVS和SVN,这些集中式的版本控制系统不但 速度慢,⽽且必须联⺴才能使⽤。有⼀些商⽤的版本控制系统,虽然⽐CVS、SVN好⽤,但 那是付费的,和 Linux的开源精神不符。 不过,到了2002年,Linux系统已经发展了⼗年了,代码库之⼤让Linus很难继续通过⼿⼯⽅ 式管理了,社区的弟兄们也对这种⽅式表达了强烈 不满,于是Linus选择了⼀个商业的版本 控制系统BitKeeper,BitKeeper的东家BitMover公司出于⼈道主义精神,授权Linux 社区免 费使⽤这个版本控制系统。 安定团结的⼤好局⾯在2005年就被打破了,原因是Linux社区⽜⼈聚集,不免沾染了⼀些梁 ⼭好汉的江湖习⽓。开发Samba的Andrew试图 破解BitKeeper的协议(这么干的其实也 不只他⼀个),被BitMover公司发现了(监控⼯作做得不错!),于是BitMover公司怒 了,要收 回Linux社区的免费使⽤权。 Linus可以向BitMover公司道个歉,保证以后严格管教弟兄们,嗯,这是不可能的。实际情 况是这样的: Linus花了两周时间⾃⼰⽤C写了⼀个分布式版本控制系统,这就是Git!⼀个月之内,Linux 系统的源码已经由Git管理了!⽜是怎么定义的呢?⼤家可以体会⼀下。 Git迅速成为最流⾏的分布式版本控制系统,尤其是2008年,GitHub⺴站上线了,它为开源 项⺫免费提供Git存储,⽆数开源项⺫开始迁移⾄GitHub,包括jQuery,PHP,Ruby等 等。 历史就是这么偶然,如果不是当年BitMover公司威胁Linux社区,可能现在我们就没有免费 ⽽超级好⽤的Git了。 Git教程 By 廖雪峰 整理、排版: numbbbbb 集中式 vs分布式 Linus⼀直痛恨的CVS及SVN都是集中式的版本控制系统,⽽Git是分布式版本控制系统,集 中式和分布式版本控制系统有什么区别呢? 先说集中式版本控制系统,版本库是集中存放在中央服务器的,⽽干活的时候,⽤的都是⾃ ⼰的电脑,所以要先从中央服务器取得最新的版本,然后开始干 活,干完活了,再把⾃⼰ 的活推送给中央服务器。中央服务器就好⽐是⼀个图书馆,你要改⼀本书,必须先从图书馆 借出来,然后回到家⾃⼰改,改完了,再放回图书馆。 集中式版本控制系统最⼤的⽑病就是必须联⺴才能⼯作,如果在局域⺴内还好,带宽够⼤, 速度够快,可如果在互联⺴上,遇到⺴速慢的话,可能提交⼀个10M的⽂件就需要5分钟, 这还不得把⼈给憋死啊。 那分布式版本控制系统与集中式版本控制系统有何不同呢?⾸先,分布式版本控制系统根本 没有“中央服务器”,每个⼈的电脑上都是⼀个完整的版本库,这 样,你⼯作的时候,就 不需要联⺴了,因为版本库就在你⾃⼰的电脑上。既然每个⼈电脑上都有⼀个完整的版本 库,那多个⼈如何协作呢?⽐⽅说你在⾃⼰电脑上改 了⽂件A,你的同事也在他的电脑上改 了⽂件A,这时,你们俩之间只需把各⾃的修改推送给对⽅,就可以互相看到对⽅的修改 了。 和集中式版本控制系统相⽐,分布式版本控制系统的安全性要⾼很多,因为每个⼈电脑⾥都 有完整的版本库,某⼀个⼈的电脑坏掉了不要紧,随便从其他⼈那⾥复制⼀个就可以了。⽽ 集中式版本控制系统的中央服务器要是出了问题,所有⼈都没法干活了。 在实际使⽤分布式版本控制系统的时候,其实很少在两⼈之间的电脑上推送版本库的修改, 因为可能你们俩不在⼀个局域⺴内,两台电脑互相访问不了,也可 能今天你的同事病了, 他的电脑压根没有开机。因此,分布式版本控制系统通常也有⼀台充当“中央服务器”的电 脑,但这个服务器的作⽤仅仅是⽤来⽅便“交换” ⼤家的修改,没有它⼤家也⼀样干活, 只是交换修改不⽅便⽽已。 Git教程 By 廖雪峰 整理、排版: numbbbbb 当然,Git的优势不单是不必联⺴这么简单,后⾯我们还会看到Git极其强⼤的分⽀管理,把 SVN等远远抛在了后⾯。 CVS作为最早的开源⽽且免费的集中式版本控制系统,直到现在还有不少⼈在⽤。由于CVS ⾃⾝设计的问题,会造成提交⽂件不完整,版本库莫名其妙损坏的情况。同样是开源⽽且免 费的SVN修正了CVS的⼀些稳定性问题,是⺫前⽤得最多的集中式版本库控制系统。 除了免费的外,还有收费的集中式版本控制系统,⽐如IBM的ClearCase(以前是Rational 公司的,被IBM收购了),特点是安装⽐ Windows还⼤,运⾏⽐蜗⽜还慢,能⽤ ClearCase的⼀般是世界500强,他们有个共同的特点是财⼤⽓粗,或者⼈傻钱多。 微软⾃⼰也有⼀个集中式版本控制系统叫VSS,集成在Visual Studio中。由于其反⼈类的设 计,连微软⾃⼰都不好意思⽤了。 分布式版本控制系统除了Git以及促使Git诞⽣的BitKeeper外,还有类似Git的Mercurial和 Bazaar等。这些分布式版本控制系统各有特点,但最快、最简单也最流⾏的依然是Git! Git教程 By 廖雪峰 整理、排版: numbbbbb 安装 Git 最早Git是在Linux上开发的,很⻓⼀段时间内,Git也只能在Linux和Unix系统上跑。不过, 慢慢地有⼈把它移植到了Windows上。现在,Git可以在Linux、Unix、Mac和Windows这 ⼏⼤平台上正常运⾏了。 要使⽤Git,第⼀步当然是安装Git了。根据你当前使⽤的平台来阅读下⾯的⽂字: Git教程 By 廖雪峰 整理、排版: numbbbbb 在 Linux上安装 Git ⾸先,你可以试着输⼊git,看看系统有没有安装Git: $ git The program 'git' is currently not installed. You can install it by typing: $ sudo apt-get install git 像上⾯的命令,有很多Linux会友好地告诉你Git没有安装,还会告诉你如何安装Git。 如果你碰巧⽤Debian或Ubuntu Linux,通过⼀条“ sudo apt-get install git”就可以直接完 成Git的安装,⾮常简单。 ⽼⼀点的Debian或Ubuntu Linux,要把命令改为“ sudo apt-get install git-core”,因为以前 有个软件也叫GIT(GNU Interactive Tools),结果Git就只能叫git-core了。由于Git名⽓ 实在太⼤,后来就把GNU Interactive Tools改成gnuit,git-core正式改为git。 如果是其他Linux版本,可以直接通过源码安装。先从Git官⺴下载源码,然后解压,依次输 ⼊: ./config,make,sudo make install这⼏个命令安装就好了。 Git教程 By 廖雪峰 整理、排版: numbbbbb 在 Mac OS X上安装 Git 如果你正在使⽤Mac做开发,有两种安装Git的⽅法。 ⼀是安装homebrew,然后通过homebrew安装Git,具体⽅法请参考homebrew的⽂ 档: http://brew.sh/。 第⼆种⽅法更简单,也是推荐的⽅法,就是直接从AppStore安装Xcode,Xcode集成了 Git,不过默认没有安装,你需要运⾏ Xcode,选择菜单“Xcode”->“Preferences”, 在弹出窗⼝中找到“Downloads”,选择“Command Line Tools”,点“Install”就可 以完成安装了。 Xcode是Apple官⽅IDE,功能⾮常强⼤,是开发Mac和iOS App的必选装备,⽽且是免费 的! Git教程 By 廖雪峰 整理、排版: numbbbbb 在 Windows上安装 Git 实话实说,Windows是最烂的开发平台,如果不是开发Windows游戏或者在IE⾥调试⻚ ⾯,⼀般不推荐⽤Windows。不过,既然已经上了微软的贼船,也是有办法安装Git的。 Windows下要使⽤很多Linux/Unix的⼯具时,需要Cygwin这样的模拟环境,Git也⼀样。 Cygwin的安装和配置都⽐较复杂, 就不建议你折腾了。不过,有⾼⼈已经把模拟环境和 Git都打包好了,名叫msysgit,只需要下载⼀个单独的exe安装程序,其他什么也不⽤装, 绝对好 ⽤。 msysgit是Windows版的Git,从 http://msysgit.github.io/下载,然后按默认选项安装即 可。 安装完成后,在开始菜单⾥找到“Git”->“Git Bash”,蹦出⼀个类似命令⾏窗⼝的东 ⻄,就说明Git安装成功! 安装完成后,还需要最后⼀步设置,在命令⾏输⼊: $ git config --global user.name "Your Name" $ git config --global user.email "email@example.com" 因为Git是分布式版本控制系统,所以,每个机器都必须⾃报家⻔:你的名字和Email地址。 你也许会担⼼,如果有⼈故意冒充别⼈怎么办?这个不必担⼼,⾸先我们相信⼤家都是善良 ⽆知的群众,其次,真的有冒充的也是有办法可查的。 注意 git config命令的--global参数,⽤了这个参数,表⽰你这台机器上所有的Git仓库都会 使⽤这个配置,当然也可以对某个仓库指定不同的⽤户名和Email地址。 Git教程 By 廖雪峰 整理、排版: numbbbbb 创建版本库 什么是版本库呢?版本库⼜名仓库,英⽂名 repository,你可以简单理解成⼀个⺫录,这个 ⺫录⾥⾯的所有⽂件都可以被Git管理起来,每个⽂件的修改、删除,Git都能跟踪,以便任 何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。 所以,创建⼀个版本库⾮常简单,⾸先,选择⼀个合适的地⽅,创建⼀个空⺫录: $ mkdir learngit $ cd learngit $ pwd /Users/michael/learngit pwd命令⽤于显⽰当前⺫录。在我的Mac上,这个仓库位于 /Users/michael/learngit。 如果你使⽤Windows系统,为了避免遇到各种莫名其妙的问题,请确保⺫录名(包括⽗⺫ 录)不包含中⽂。 第⼆步,通过git init命令把这个⺫录变成Git可以管理的仓库: $ git init Initialized empty Git repository in /Users/michael/learngit/.git/ 瞬间Git就把仓库建好了,⽽且告诉你是⼀个空的仓库(empty Git repository),细⼼的 读者可以发现当前⺫录下多了⼀个.git的⺫录,这个⺫录是Git来跟踪管理版本库的,没事千 万不要⼿动修改这个⺫录⾥⾯ 的⽂件,不然改乱了,就把Git仓库给破坏了。 也不⼀定必须在空⺫录下创建Git仓库,选择⼀个已经有东⻄的⺫录也是可以的。不过,不 建议你使⽤⾃⼰正在开发的公司项⺫来学习Git,否则造成的⼀切后果概不负责。 把⽂件添加到版本库 ⾸先这⾥再明确⼀下,所有的版本控制系统,其实只能跟踪⽂本⽂件的改动,⽐如TXT⽂ 件,⺴⻚,所有的程序代码等等,Git也不例外。版本控制系统 可以告诉你每次的改动,⽐ 如在第5⾏加了⼀个单词“Linux”,在第8⾏删了⼀个单词“Windows”。⽽图⽚、视频这 些⼆进制⽂件,虽然也能由版本 控制系统管理,但没法跟踪⽂件的变化,只能把⼆进制⽂ 件每次改动串起来,也就是只知道图⽚从100KB改成了120KB,但到底改了啥,版本控制系 统不知 道,也没法知道。 不幸的是,Microsoft的Word格式是⼆进制格式,因此,版本控制系统是没法跟踪Word⽂ 件的改动的,前⾯我们举的例⼦只是为了演⽰,如果要真正使⽤版本控制系统,就要以纯⽂ 本⽅式编写⽂件。 因为⽂本是有编码的,⽐如中⽂有常⽤的GBK编码,⽇⽂有Shift_JIS编码,如果没有历史遗 留问题,强烈建议使⽤标准的UTF-8编码,所有语⾔使⽤同⼀种编码,既没有冲突,⼜被所 有平台所⽀持。 使用Windows的童鞋要特别注意: 千万不要使⽤Windows⾃带的 记事本 编辑任何⽂本⽂件。原因是Microsoft开发记事本的团 队使⽤了⼀ 个⾮常弱智的⾏为来保存UTF-8编码的⽂件,他们⾃作聪明地在每个⽂件开头添 加了0xefbbbf(⼗六进制)的字符,你会遇到很多不可思议的问题,⽐ 如,⺴⻚第⼀⾏可 能会显⽰⼀个“?”,明明正确的程序⼀编译就报语法错误,等等,都是由记事本的弱智⾏ 为带来的。建议你下载 Notepad++代替记事本,不但功能强⼤,⽽且免费!记得把 Notepad++的默认编码设置为UTF-8 without BOM即可: Git教程 By 廖雪峰 整理、排版: numbbbbb ⾔归正传,现在我们编写⼀个readme.txt⽂件,内容如下: Git is a version control system. Git is free software. ⼀定要放到learngit⺫录下(⼦⺫录也⾏),因为这是⼀个Git仓库,放到其他地⽅Git再厉 害也找不到这个⽂件。 和把⼤象放到冰箱需要3步相⽐,把⼀个⽂件放到Git仓库只需要两步。 第⼀步,⽤命令 git add告诉Git,把⽂件添加到仓库: $ git add readme.txt 执⾏上⾯的命令,没有任何显⽰,这就对了,Unix的哲学是“没有消息就是好消息”,说明 添加成功。 第⼆步,⽤命令 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 100644 readme.txt 简单解释⼀下 git commit命令, -m后⾯输⼊的是本次提交的说明,可以输⼊任意内容,当然 最好是有意义的,这样你就能从历史记录⾥⽅便地找到改动记录。 嫌⿇烦不想输⼊ -m "xxx"⾏不⾏?确实有办法可以这么干,但是强烈不建议你这么干,因为 输⼊说明对⾃⼰对别⼈阅读都很重要。实在不想输⼊说明的童鞋请⾃⾏Google,我不告诉 你这个参数。 git commit命令执⾏成功后会告诉你,1个⽂件被改动(我们新添加的readme.txt⽂件), 插⼊了两⾏内容(readme.txt有两⾏内容)。 Git教程 By 廖雪峰 整理、排版: numbbbbb 为什么Git添加⽂件需要 add, commit⼀共两步呢?因为commit可以⼀次提交很多⽂件, 所以你可以多次add不同的⽂件,⽐如: $ git add file1.txt $ git add file2.txt $ git add file3.txt $ git commit -m "add 3 files." ⼩结 现在总结⼀下今天学的两点内容: 初始化⼀个Git仓库,使⽤ git init命令。 添加⽂件到Git仓库,分两步: • 第⼀步,使⽤命令 git add ,注意,可反复多次使⽤,添加多个⽂件; • 第⼆步,使⽤命令 git commit,完成。 Git教程 By 廖雪峰 整理、排版: numbbbbb 时光机穿梭 我们已经成功地添加并提交了⼀个readme.txt⽂件,现在,是时候继续⼯作了,于是,我 们继续修改readme.txt⽂件,改成如下内容: Git is a distributed version control system. Git is free software. 现在,运⾏ git status命令看看结果: $ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: readme.txt # no changes added to commit (use "git add" and/or "git commit -a") git status命令可以让我们时刻掌握仓库当前的状态,上⾯的命令告诉我们,readme.txt被 修改过了,但还没有准备提交的修改。 虽然Git告诉我们readme.txt被修改了,但如果能看看具体修改了什么内容,⾃然是很好 的。⽐如你休假两周从国外回来,第⼀天上班时,已经记不清上次怎么修改的 readme.txt,所以,需要⽤ git diff这个命令看看: $ git diff readme.txt diff --git a/readme.txt b/readme.txt index 46d49bf..9247db6 100644 --- a/readme.txt +++ b/readme.txt @@ -1,2 +1,2 @@ -Git is a version control system. +Git is a distributed version control system. Git is free software. git diff顾名思义就是查看difference,显⽰的格式正是Unix通⽤的diff格式,可以从上⾯的 命令输出看到,我们在第⼀⾏添加了⼀个“distributed”单词。 知道了对readme.txt作了什么修改后,再把它提交到仓库就放⼼多了,提交修改和提交新 ⽂件是⼀样的两步,第⼀步是 git add: $ git add readme.txt 同样没有任何输出。在执⾏第⼆步 git commit之前,我们再运⾏ git status看看当前仓库的状 态: $ git status # On branch master Git教程 By 廖雪峰 整理、排版: numbbbbb # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: readme.txt # git status告诉我们,将要被提交的修改包括readme.txt,下⼀步,就可以放⼼地提交了: $ git commit -m "add distributed" [master ea34578] add distributed 1 file changed, 1 insertion(+), 1 deletion(-) 提交后,我们再⽤ git status命令看看仓库的当前状态: $ git status # On branch master nothing to commit (working directory clean) Git告诉我们当前没有需要提交的修改,⽽且,⼯作⺫录是干净(working directory clean)的。 ⼩结 • 要随时掌握⼯作区的状态,使⽤ git status命令。 • 如果 git status告诉你有⽂件被修改过,⽤ git diff可以查看修改内容。 Git教程 By 廖雪峰 整理、排版: numbbbbb 版本回退 现在,你已经学会了修改⽂件,然后把修改提交到Git版本库,现在,再练习⼀次,修改 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" [master 3628164] append GPL 1 file changed, 1 insertion(+), 1 deletion(-) 像这样,你不断对⽂件进⾏修改,然后不断提交修改到版本库⾥,就好⽐玩RPG游戏时,每 通过⼀关就会⾃动把游戏状态存 盘,如果某⼀关没过去,你还可以选择读取前⼀关的状 态。有些时候,在打Boss之前,你会⼿动存盘,以便万⼀打Boss失败了,可以从最近的地⽅ 重新开 始。Git也是⼀样,每当你觉得⽂件修改到⼀定程度的时候,就可以“保存⼀个快 照”,这个快照在Git中被称为commit。⼀旦你把⽂件改乱了,或者误 删了⽂件,还可以 从最近的⼀个commit恢复,然后继续⼯作,⽽不是把⼏个月的⼯作成果全部丢失。 现在,我们回顾⼀下readme.txt⽂件⼀共有⼏个版本被提交到Git仓库⾥了: 版本1:wrote a readme file Git is a version control system. Git is free software. 版本2:add distributed Git is a distributed version control system. Git is free software. 版本3:append GPL Git is a distributed version control system. Git is free software distributed under the GPL. 当然了,在实际⼯作中,我们脑⼦⾥怎么可能记得⼀个⼏千⾏的⽂件每次都改了什么内容, 不然要版本控制系统干什么。版本控制系统肯定有某个命令可以告诉我们历史记录,在Git 中,我们⽤ git log命令查看: $ git log commit 3628164fb26d48395383f8f31179f24e0882e1e0 Author: Michael Liao Date: Tue Aug 20 15:11:49 2013 +0800 append GPL commit ea34578d5496d7dd233c827ed32a8cd576c5ee85 Author: Michael Liao Date: Tue Aug 20 14:53:12 2013 +0800 Git教程 By 廖雪峰 整理、排版: numbbbbb add distributed commit cb926e7ea50ad11b8f9e909c05226233bf755030 Author: Michael Liao Date: Mon Aug 19 17:51:55 2013 +0800 wrote a readme file git log命令显⽰从最近到最远的提交⽇志,我们可以看到3次提交,最近的⼀次 是“append GPL”,上⼀次是“add distributed”,最早的⼀次是“wrote a readme file”。 如果嫌输出信息太多,看得眼花缭乱的,可以试试加上 --pretty=oneline参数: $ git log --pretty=oneline 3628164fb26d48395383f8f31179f24e0882e1e0 append GPL ea34578d5496d7dd233c827ed32a8cd576c5ee85 add distributed cb926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file 需要友情提⽰的是,你看到的⼀⼤串类似“ 3628164...882e1e0”的是commit id(版本 号),和SVN不⼀样,Git的commit id不是1,2,3……递增的数字,⽽是⼀个SHA1计算 出来的⼀个⾮常⼤的数字,⽤⼗六进制表⽰,⽽且你看到的commit id和我的肯定不⼀样, 以你⾃⼰的为准。为什么commit id需要⽤这么⼀⼤串数字表⽰呢?因为Git是分布式的版 本控制系统,后⾯我们还要研究多⼈在同⼀个版本库⾥⼯作,如果⼤家都⽤1,2,3……作 为版本 号,那肯定就冲突了。 每提交⼀个新版本,实际上Git就会把它们⾃动串成⼀条时间线。如果使⽤可视化⼯具查看 Git历史,就可以更清楚地看到提交历史的时间线: 好了,现在我们启动时光穿梭机,准备把readme.txt回退到上⼀个版本,也就是“add distributed”的那个版本,怎么做呢? ⾸先,Git必须知道当前版本是哪个版本,在Git中,⽤HEAD表⽰当前版本,也就是最新的 提交“ 3628164...882e1e0”(注意我的提交ID和你的肯定不⼀样),上⼀个版本就是 HEAD^,上上⼀个版本就是HEAD^^,当然往上100 个版本写100个^⽐较容易数不过来, 所以写成HEAD~100。 现在,我们要把当前版本“append GPL”回退到上⼀个版本“add distributed”,就可 以使⽤ git reset命令: $ git reset --hard HEAD^ Git教程 By 廖雪峰 整理、排版: numbbbbb HEAD is now at ea34578 add distributed --hard参数有啥意义?这个后⾯再讲,现在你先放⼼使⽤。 看看readme.txt的内容是不是版本“add distributed”: $ cat readme.txt Git is a distributed version control system. Git is free software. 果然。 还可以继续回退到上⼀个版本“wrote a readme file”,不过且慢,然我们⽤ git log再看 看现在版本库的状态: $ git log commit ea34578d5496d7dd233c827ed32a8cd576c5ee85 Author: Michael Liao Date: Tue Aug 20 14:53:12 2013 +0800 add distributed commit cb926e7ea50ad11b8f9e909c05226233bf755030 Author: Michael Liao Date: Mon Aug 19 17:51:55 2013 +0800 wrote a readme file 最新的那个版本“append GPL”已经看不到了!好⽐你从21世纪坐时光穿梭机来到了19 世纪,想再回去已经回不去了,肿么办? 办法其实还是有的,只要上⾯的命令⾏窗⼝还没有被关掉,你就可以顺着往上找啊找啊,找 到那个“append GPL”的commit id是“3628164...”,于是就可以指定回到未来的某个 版本: $ git reset --hard 3628164 HEAD is now at 3628164 append GPL 版本号没必要写全,前⼏位就可以了,Git会⾃动去找。当然也不能只写前⼀两位,因为Git 可能会找到多个版本号,就⽆法确定是哪⼀个了。 再⼩⼼翼翼地看看readme.txt的内容: $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. 果然,我胡汉⼭⼜回来了。 Git的版本回退速度⾮常快,因为Git在内部有个指向当前版本的HEAD指针,当你回退版本 的时候,Git仅仅是把HEAD从指向“append GPL”: Git教程 By 廖雪峰 整理、排版: numbbbbb 改为指向“add distributed”: 然后顺便把⼯作区的⽂件更新了。所以你让HEAD指向哪个版本号,你就把当前版本定位在 哪。 现在,你回退到了某个版本,关掉了电脑,第⼆天早上就后悔了,想恢复到新版本怎么办? 找不到新版本的commit id怎么办? 在Git中,总是有后悔药可以吃的。当你⽤ $ git reset --hard HEAD^回退到“add distributed”版本时,再想恢复到“append GPL”,就必须找到“append GPL”的 commit id。Git提供了⼀个命令 git reflog⽤来记录你的每⼀次命令: $ git reflog ea34578 HEAD@{0}: reset: moving to HEAD^ 3628164 HEAD@{1}: commit: append GPL ea34578 HEAD@{2}: commit: add distributed cb926e7 HEAD@{3}: commit (initial): wrote a readme file 终于舒了⼝⽓,第⼆⾏显⽰“append GPL”的commit id是3628164,现在,你⼜可以乘 坐时光机回到未来了。 ⼩结 现在总结⼀下: • HEAD指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使⽤命 令 git reset --hard commit_id。 Git教程 By 廖雪峰 整理、排版: numbbbbb • 穿梭前,⽤ git log可以查看提交历史,以便确定要回退到哪个版本。 • 要重返未来,⽤ git reflog查看命令历史,以便确定要回到未来的哪个版本。 Git教程 By 廖雪峰 整理、排版: numbbbbb ⼯作区和暂存区 Git和其他版本控制系统如SVN的⼀个不同之处就是有暂存区的概念。 先来看名词解释。 ⼯作区 (Working Directory):就是你在电脑⾥能看到的⺫录,⽐如我的learngit⽂件夹 就是⼀个⼯作区: 版本库 (Repository):⼯作区有⼀个隐藏⺫录“.git”,这个不算⼯作区,⽽是Git的版本 库。 Git的版本库⾥存了很多东⻄,其中最重要的就是称为stage(或者叫index)的暂存区,还 有Git为我们⾃动创建的第⼀个分⽀master,以及指向master的⼀个指针叫HEAD。 Git教程 By 廖雪峰 整理、排版: numbbbbb 分⽀和HEAD的概念我们以后再讲。 前⾯讲了我们把⽂件往Git版本库⾥添加的时候,是分两步执⾏的: 第⼀步是⽤“ git add”把⽂件添加进去,实际上就是把⽂件修改添加到暂存区; 第⼆步是⽤“ git commit”提交更改,实际上就是把暂存区的所有内容提交到当前分⽀。 因为我们创建Git版本库时,Git⾃动为我们创建了唯⼀⼀个master分⽀,所以,现在, commit就是往master分⽀上提交更改。 你可以简单理解为,需要提交的⽂件修改通通放到暂存区,然后,⼀次性提交暂存区的所有 修改。 俗话说,实践出真知。现在,我们再练习⼀遍,先对readme.txt做个修改,⽐如加上⼀⾏ 内容: Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. 然后,在⼯作区新增⼀个LICENSE⽂本⽂件(内容随便写)。 先⽤ git status查看⼀下状态: $ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: readme.txt # # Untracked files: # (use "git add ..." to include in what will be committed) Git教程 By 廖雪峰 整理、排版: numbbbbb # # LICENSE no changes added to commit (use "git add" and/or "git commit -a") Git⾮常清楚地告诉我们, readme.txt被修改了,⽽ LICENSE还从来没有被添加过,所以它 的状态是Untracked。 现在,使⽤两次命令 git add,把readme.txt和LICENSE都添加后,⽤ git status再查看⼀ 下: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # new file: LICENSE # modified: readme.txt # 现在,暂存区的状态就变成这样了: 所以, git add命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执⾏ git commit就可以⼀次性把暂存区的所有修改提交到分⽀。 $ git commit -m "understand how stage works" [master 27c9860] understand how stage works 2 files changed, 675 insertions(+) create mode 100644 LICENSE ⼀旦提交后,如果你⼜没有对⼯作区做任何修改,那么⼯作区就是“干净”的: $ git status # On branch master nothing to commit (working directory clean) Git教程 By 廖雪峰 整理、排版: numbbbbb 现在版本库变成了这样,暂存区就没有任何内容了: ⼩结 暂存区是Git⾮常重要的概念,弄明⽩了暂存区,就弄明⽩了Git的很多操作到底干了什么。 没弄明⽩暂存区是怎么回事的童鞋,请向上滚动⻚⾯,再看⼀次。 Git教程 By 廖雪峰 整理、排版: numbbbbb 管理修改 现在,假定你已经完全掌握了暂存区的概念。下⾯,我们要讨论的就是,为什么Git⽐其他 版本控制系统设计得优秀,因为Git跟踪并管理的是修改,⽽⾮⽂件。 你会问,什么是修改?⽐如你新增了⼀⾏,这就是⼀个修改,删除了⼀⾏,也是⼀个修改, 更改了某些字符,也是⼀个修改,删了⼀些⼜加了⼀些,也是⼀个修改,甚⾄创建⼀个新⽂ 件,也算⼀个修改。 为什么说Git管理的是修改,⽽不是⽂件呢?我们还是做实验。第⼀步,对readme.txt做⼀ 个修改,⽐如加⼀⾏内容: $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes. 然后,添加: $ git add readme.txt $ git status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: readme.txt # 然后,再修改readme.txt: $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. 提交: $ git commit -m "git tracks changes" [master d4f25b6] git tracks changes 1 file changed, 1 insertion(+) 提交后,再看看状态: $ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: readme.txt Git教程 By 廖雪峰 整理、排版: numbbbbb # no changes added to commit (use "git add" and/or "git commit -a") 咦,怎么第⼆次的修改没有被提交? 别激动,我们回顾⼀下操作过程: 第⼀次修改 -> git add -> 第⼆次修改 -> git commit 你看,我们前⾯讲了,Git管理的是修改,当你⽤“ git add”命令后,在⼯作区的第⼀次修 改被放⼊暂存区,准备提交,但是,在⼯作区的第⼆次修改并没有放⼊暂存区,所 以,“ git commit”只负责把暂存区的修改提交了,也就是第⼀次的修改被提交了,第⼆次 的修改不会被提交。 提交后,⽤“ git diff HEAD -- readme.txt”命令可以查看⼯作区和版本库⾥⾯最新版本的区 别: $ git diff HEAD -- readme.txt diff --git a/readme.txt b/readme.txt index 76d770f..a9c5755 100644 --- a/readme.txt +++ b/readme.txt @@ -1,4 +1,4 @@ Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. -Git tracks changes. +Git tracks changes of files. 可⻅,第⼆次修改确实没有被提交。 那怎么提交第⼆次修改呢?你可以继续add再commit,也可以别着急提交第⼀次修改,先 add第⼆次修改,再commit,就相当于把两次修改合并后⼀块提交了: 第⼀次修改 -> add -> 第⼆次修改 -> add -> commit 好,现在,把第⼆次修改提交了,然后开始⼩结。 ⼩结 现在,你⼜理解了Git是如何跟踪修改的,每次修改,如果不add到暂存区,那就不会加⼊ 到commit中。 Git教程 By 廖雪峰 整理、排版: numbbbbb 撤销修改 ⾃然,你是不会犯错的。不过现在是凌晨两点,你正在赶⼀份⼯作报告,你在readme.txt 中添加了⼀⾏: $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. My stupid boss still prefers SVN. 在你准备提交前,⼀杯咖啡起了作⽤,你猛然发现了“stupid boss”可能会让你丢掉这个 月的奖⾦! 既然错误发现得很及时,就可以很容易地纠正它。你可以删掉最后⼀⾏,⼿动把⽂件恢复到 上⼀个版本的状态。如果⽤ git status查看⼀下: $ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: readme.txt # no changes added to commit (use "git add" and/or "git commit -a") 你可以发现,Git会告诉你, git checkout -- file可以丢弃⼯作区的修改: $ git checkout -- readme.txt 命令 git checkout -- readme.txt意思就是,把readme.txt⽂件在⼯作区的修改全部撤销,这 ⾥有两种情况: ⼀种是readme.txt⾃修改后还没有被放到暂存区,现在,撤销修改就回到和版本库⼀模⼀ 样的状态; ⼀种是readme.txt已经添加到暂存区后,⼜作了修改,现在,撤销修改就回到添加到暂存 区后的状态。 总之,就是让这个⽂件回到最近⼀次 git commit或 git add时的状态。 现在,看看readme.txt的⽂件内容: $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. ⽂件内容果然复原了。 Git教程 By 廖雪峰 整理、排版: numbbbbb git checkout -- file命令中的“--”很重要,没有“--”,就变成了“创建⼀个新分⽀”的命 令,我们在后⾯的分⽀管理中会再次遇到 git checkout命令。 现在假定是凌晨3点,你不但写了⼀些胡话,还 git add到暂存区了: $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. My stupid boss still prefers SVN. $ git add readme.txt 庆幸的是,在commit之前,你发现了这个问题。⽤ git status查看⼀下,修改只是添加到了 暂存区,还没有提交: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: readme.txt # Git同样告诉我们,⽤命令 git reset HEAD file可以把暂存区的修改撤销掉(unstage),重 新放回⼯作区: $ git reset HEAD readme.txt Unstaged changes after reset: M readme.txt git reset命令既可以回退版本,也可以把暂存区的修改回退到⼯作区。当我们⽤HEAD时, 表⽰最新的版本。 再⽤ git status查看⼀下,现在暂存区是干净的,⼯作区有修改: $ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: readme.txt # no changes added to commit (use "git add" and/or "git commit -a") 还记得如何丢弃⼯作区的修改吗? $ git checkout -- readme.txt Git教程 By 廖雪峰 整理、排版: numbbbbb $ git status # On branch master nothing to commit (working directory clean) 整个世界终于清静了! 现在,假设你不但改错了东⻄,还从暂存区提交到了版本库,怎么办呢?还记得 版本回退 ⼀ 节吗?可以回退到上⼀个版本。不过,这是有条件的,就是你还没有把⾃⼰的本地版本库推 送到远程。还记得Git是分布式版本控制系统吗?我们后⾯会讲到远程版本库,⼀旦你 把“stupid boss”提交推送到远程版本库,你就真的惨了…… ⼩结 ⼜到了⼩结时间。 场景1:当你改乱了⼯作区某个⽂件的内容,想直接丢弃⼯作区的修改时,⽤命令 git checkout -- file。 场景2:当你不但改乱了⼯作区某个⽂件的内容,还添加到了暂存区时,想丢弃修改,分两 步,第⼀步⽤命令 git reset HEAD file,就回到了场景1,第⼆步按场景1操作。 场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考 版本回退 ⼀节,不 过前提是没有推送到远程库。 Git教程 By 廖雪峰 整理、排版: numbbbbb 删除⽂件 在Git中,删除也是⼀个修改操作,我们实战⼀下,先添加⼀个新⽂件test.txt到Git并且提 交: $ git add test.txt $ git commit -m "add test.txt" [master 94cdc44] add test.txt 1 file changed, 1 insertion(+) create mode 100644 test.txt ⼀般情况下,你通常直接在⽂件管理器中把没⽤的⽂件删了,或者⽤ rm命令删了: $ rm test.txt 这个时候,Git知道你删除了⽂件,因此,⼯作区和版本库就不⼀致了, git status命令会⽴ 刻告诉你哪些⽂件被删除了: $ git status # On branch master # Changes not staged for commit: # (use "git add/rm ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # deleted: test.txt # no changes added to commit (use "git add" and/or "git commit -a") 现在你有两个选择,⼀是确实要从版本库中删除该⽂件,那就⽤命令 git rm删掉,并且 commit: $ git rm test.txt rm 'test.txt' $ git commit -m "remove test.txt" [master d17efd8] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt 现在,⽂件就从版本库中被删除了。 另⼀种情况是删错了,因为版本库⾥还有呢,所以可以很轻松地把误删的⽂件恢复到最新版 本: $ git checkout -- test.txt git checkout其实是⽤版本库⾥的版本替换⼯作区的版本,⽆论⼯作区是修改还是删除,都 可以“⼀键还原”。 小结 Git教程 By 廖雪峰 整理、排版: numbbbbb 命令 git rm⽤于删除⼀个⽂件。如果⼀个⽂件已经被提交到版本库,那么你永远不⽤担⼼误 删,但是要⼩⼼,你只能恢复⽂件到最新版本,你会丢失 最近⼀次提交后你修改的内容 。 Git教程 By 廖雪峰 整理、排版: numbbbbb 远程仓库 到⺫前为⽌,我们已经掌握了如何在Git仓库⾥对⼀个⽂件进⾏时光穿梭,你再也不⽤担⼼ ⽂件备份或者丢失的问题了。 可是有⽤过集中式版本控制系统SVN的童鞋会站出来说,这些功能在SVN⾥早就有了,没看 出Git有什么特别的地⽅。 没错,如果只是在⼀个仓库⾥管理⽂件历史,Git和SVN真没啥区别。为了保证你现在所学 的Git物超所值,将来绝对不会后悔,同时为了打击已经不幸学了SVN的童鞋,本章开始介 绍Git的杀⼿级功能之⼀(注意是之⼀,也就是后⾯还有之⼆,之三……):远程仓库。 Git是分布式版本控制系统,同⼀个Git仓库,可以分布到不同的机器上。怎么分布呢?最 早,肯定只有⼀台机器有⼀个原始版本库,此后,别的机器可以“克隆”这个原始版本库, ⽽且每台机器的版本库其实都是⼀样的,并没有主次之分。 你肯定会想,⾄少需要两台机器才能玩远程库不是?但是我只有⼀台电脑,怎么玩? 其实⼀台电脑上也是可以克隆多个版本库的,只要不在同⼀个⺫录下。不过,现实⽣活中是 不会有⼈这么傻的在⼀台电脑上搞⼏个远程库玩,因为⼀台电脑上搞⼏个远程库完全没有意 义,⽽且硬盘挂了会导致所有库都挂掉,所以我也不告诉你在⼀台电脑上怎么克隆多个仓 库。 实际情况往往是这样,找⼀台电脑充当服务器的⾓⾊,每天24⼩时开机,其他每个⼈都从这 个“服务器”仓库克隆⼀份到⾃⼰的电脑上,并且各⾃把各⾃的提交推送到服务器仓库⾥, 也从服务器仓库中拉取别⼈的提交。 完全可以⾃⼰搭建⼀台运⾏Git的服务器,不过现阶段,为了学Git先搭个服务器绝对是⼩题 ⼤作。好在这个世界上有个叫 GitHub的神奇的⺴站,从名字就可以看出,这个⺴站就是提 供Git仓库托管服务的,所以,只要注册⼀个GitHub账号,就可以免费获得Git远程仓库。 在继续阅读后续内容前,请⾃⾏注册GitHub账号。由于你的本地Git仓库和GitHub仓库之 间的传输是通过SSH加密的,所以,需要⼀点设置: 第1步:创建SSH Key。在⽤户主⺫录下,看看有没有.ssh⺫录,如果有,再看看这个⺫录下 有没有id_rsa和id_rsa.pub这两个⽂件,如果已经有了,可直接 跳到下⼀步。如果没有,打 开Shell(Windows下打开Git Bash),创建SSH Key: $ ssh-keygen -t rsa -C "youremail@example.com" 你需要把邮件地址换成你⾃⼰的邮件地址,然后⼀路回⻋,使⽤默认值即可,由于这个Key 也不是⽤于军事⺫的,所以也⽆需设置密码。 如果⼀切顺利的话,可以在⽤户主⺫录⾥找到.ssh⺫录,⾥⾯有id_rsa和id_rsa.pub两个⽂ 件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可 以放⼼地告诉任何⼈。 第2步:登陆GitHub,打开“Account settings”,“SSH Keys”⻚⾯: 然后,点“Add SSH Key”,填上任意Title,在Key⽂本框⾥粘贴id_rsa.pub⽂件的内容: Git教程 By 廖雪峰 整理、排版: numbbbbb 点“Add Key”,你就应该看到已经添加的Key: 为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,⽽ 不是别⼈冒充的,⽽Git⽀持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只 有你⾃⼰才能推送。 当然,GitHub允许你添加多个Key。假定你有若干电脑,你⼀会⼉在公司提交,⼀会⼉在 家⾥提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送 了。 最后友情提⽰,在GitHub上免费托管的Git仓库,任何⼈都可以看到喔(但只有你⾃⼰才能 改)。所以,不要把敏感信息放进去。 如果你不想让别⼈看到Git库,有两个办法,⼀个是交点保护费,让GitHub把公开的仓库变 成私有的,这样别⼈就看不⻅了(不可读更不可写)。另 ⼀个办法是⾃⼰动⼿,搭⼀个Git Git教程 By 廖雪峰 整理、排版: numbbbbb 服务器,因为是你⾃⼰的Git服务器,所以别⼈也是看不⻅的。这个⽅法我们后⾯会讲到 的,相当简单,公司内部开发必备。 确保你拥有⼀个GitHub账号后,我们就即将开始远程仓库的学习。 ⼩结 “有了远程仓库,妈妈再也不⽤担⼼我的硬盘了。”——Git点读机 Git教程 By 廖雪峰 整理、排版: numbbbbb 添加远程库 现在的情景是,你已经在本地创建了⼀个Git仓库后,⼜想在GitHub创建⼀个Git仓库,并 且让这两个仓库进⾏远程同步,这样,GitHub上的仓库既可以作为备份,⼜可以让其他⼈ 通过该仓库来协作,真是⼀举多得。 ⾸先,登陆GitHub,然后,在右上⾓找到“Create a new repo”按钮,创建⼀个新的仓 库: 在Repository name填⼊ learngit,其他保持默认设置,点击“Create repository”按 钮,就成功地创建了⼀个新的Git仓库: Git教程 By 廖雪峰 整理、排版: numbbbbb ⺫前,在GitHub上的这个learngit仓库还是空的,GitHub告诉我们,可以从这个仓库克隆 出新的仓库,也可以把⼀个已有的本地仓库与之关联,然后,把本地仓库的内容推送到 GitHub仓库。 现在,我们根据GitHub的提⽰,在本地的learngit仓库下运⾏命令: $ git remote add origin git@github.com:michaelliao/learngit.git 请千万注意,把上⾯的michaelliao替换成你⾃⼰的GitHub账户名,否则,你在本地关联的 就是我的远程库,关联没有问题,但是你以后推送是推不上去的,因为你的SSH Key公钥不 在我的账户列表中。 添加后,远程库的名字就是 origin,这是Git默认的叫法,也可以改成别的,但是 origin这个 名字⼀看就知道是远程库。 下⼀步,就可以把本地库的所有内容推送到远程库上: $ git push -u origin master Counting objects: 19, done. Delta compression using up to 4 threads. Compressing objects: 100% (19/19), done. Writing objects: 100% (19/19), 13.73 KiB, done. Total 23 (delta 6), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git * [new branch] master -> master Branch master set up to track remote branch master from origin. 把本地库的内容推送到远程,⽤ git push命令,实际上是把当前分⽀master推送到远程。 Git教程 By 廖雪峰 整理、排版: numbbbbb 由于远程库是空的,我们第⼀次推送master分⽀时,加上了 -u参数,Git不但会把本地的 master分⽀内容推送的远程新的master分⽀,还会把本地的master分⽀和远程的master 分⽀关联起来,在以后的推送或者拉取时就可以简化命令。 推送成功后,可以⽴刻在GitHub⻚⾯中看到远程库的内容已经和本地⼀模⼀样: 从现在起,只要本地作了提交,就可以通过命令: $ git push origin master 把本地master分⽀的最新修改推送⾄GitHub,现在,你就拥有了真正的分布式版本库! ⼩结 要关联⼀个远程库,使⽤命令 git remote add origin git@server-name:path/repo-name.git; 关联后,使⽤命令 git push -u origin master第⼀次推送master分⽀的所有内容; 此后,每次本地提交后,只要有必要,就可以使⽤命令 git push origin master推送最新修 改; 分布式版本系统的最⼤好处之⼀是在本地⼯作完全不需要考虑远程库的存在,也就是有没有 联⺴都可以正常⼯作,⽽SVN在没有联⺴的时候是拒绝干活的!当有⺴络的时候,再把本地 提交推送⼀下就完成了同步,真是太⽅便了! Git教程 By 廖雪峰 整理、排版: numbbbbb 从远程库克隆 上次我们讲了先有本地库,后有远程库的时候,如何关联远程库。 现在,假设我们从零开发,那么最好的⽅式是先创建远程库,然后,从远程库克隆。 ⾸先,登陆GitHub,创建⼀个新的仓库,名字叫gitskills: 我们勾选 Initialize this repository with a README,这样GitHub会⾃动为我们创建⼀个 README.md⽂件。创建完毕后,可以看到README.md⽂件: Git教程 By 廖雪峰 整理、排版: numbbbbb 现在,远程库已经准备好了,下⼀步是⽤命令 git clone克隆⼀个本地库: $ git clone git@github.com:michaelliao/gitskills.git Cloning into 'gitskills'... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Receiving objects: 100% (3/3), done. $ cd gitskills $ ls README.md 注意把Git库的地址换成你⾃⼰的,然后进⼊gitskills⺫录看看,已经有README.md⽂件 了。 如果有多个⼈协作开发,那么每个⼈各⾃从远程克隆⼀份就可以了。 你也许还注意到,GitHub给出的地址不⽌⼀个,还可以⽤ https://github.com/ michaelliao/gitskills.git这样的地址。实际上,Git⽀持多种协议,默认的git://使⽤ssh,但 也可以使⽤https等其他协议。 使⽤https除了速度慢以外,还有个最⼤的⿇烦是每次推送都必须输⼊⼝令,但是在某些只 开放http端⼝的公司内部就⽆法使⽤ssh协议⽽只能⽤https。 ⼩结 要克隆⼀个仓库,⾸先必须知道仓库的地址,然后使⽤ git clone命令克隆。 Git⽀持多种协议,包括https,但通过ssh⽀持的原⽣git协议速度最快。 Git教程 By 廖雪峰 整理、排版: numbbbbb 分⽀管理 分⽀就是科幻电影⾥⾯的平⾏宇宙,当你正在电脑前努⼒学习Git的时候,另⼀个你正在另 ⼀个平⾏宇宙⾥努⼒学习SVN。 如果两个平⾏宇宙互不干扰,那对现在的你也没啥影响。不过,在某个时间点,两个平⾏宇 宙合并了,结果,你既学会了Git⼜学会了SVN! 分⽀在实际中有什么⽤呢?假设你准备开发⼀个新功能,但是需要两周才能完成,第⼀周你 写了50%的代码,如果⽴刻提交,由于代码还没写完,不完整的代码库会导致别⼈不能干活 了。如果等代码全部写完再⼀次提交,⼜存在丢失每天进度的巨⼤⻛险。 现在有了分⽀,就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀,别⼈看不到,还继续在原来 的分⽀上正常⼯作,⽽你在⾃⼰的分⽀上干活,想提交就提交,直到开发完毕后,再⼀次性 合并到原来的分⽀上,这样,既安全,⼜不影响别⼈⼯作。 其他版本控制系统如SVN等都有分⽀管理,但是⽤过之后你会发现,这些版本控制系统创建 和切换分⽀⽐蜗⽜还慢,简直让⼈⽆法忍受,结果分⽀功能成了摆设,⼤家都不去⽤。 但Git的分⽀是与众不同的,⽆论创建、切换和删除分⽀,Git在1秒钟之内就能完成!⽆论 你的版本库是1个⽂件还是1万个⽂件。 Git教程 By 廖雪峰 整理、排版: numbbbbb 创建与合并分⽀ 在 版本回退 ⾥, 你已经知道,每次提交,Git都把它们串成⼀条时间线,这条时间线就是⼀ 个分⽀。截⽌到⺫前,只有⼀条时间线,在Git⾥,这个分⽀叫主分⽀,即 master分⽀。 HEAD严格来说不是指向提交,⽽是指向master,master才是指向提交的,所以,HEAD指 向的就是当前分⽀。 ⼀开始的时候,master分⽀是⼀条线,Git⽤master指向最新的提交,再⽤HEAD指向 master,就能确定当前分⽀,以及当前分⽀的提交点: 每次提交,master分⽀都会向前移动⼀步,这样,随着你不断提交,master分⽀的线也越 来越⻓。 当我们创建新的分⽀,例如dev时,Git新建了⼀个指针叫dev,指向master相同的提交, 再把HEAD指向dev,就表⽰当前分⽀在dev上: 你看,Git创建⼀个分⽀很快,因为除了增加⼀个dev指针,改改HEAD的指向,⼯作区的⽂ 件都没有任何变化! 不过,从现在开始,对⼯作区的修改和提交就是针对dev分⽀了,⽐如新提交⼀次后,dev 指针往前移动⼀步,⽽master指针不变: Git教程 By 廖雪峰 整理、排版: numbbbbb 假如我们在dev上的⼯作完成了,就可以把dev合并到master上。Git怎么合并呢?最简单 的⽅法,就是直接把master指向dev的当前提交,就完成了合并: 所以Git合并分⽀也很快!就改改指针,⼯作区内容也不变! 合并完分⽀后,甚⾄可以删除dev分⽀。删除dev分⽀就是把dev指针给删掉,删掉后,我 们就剩下了⼀条master分⽀: Git教程 By 廖雪峰 整理、排版: numbbbbb 真是太神奇了,你看得出来有些提交是通过分⽀完成的吗? 下⾯开始实战。 ⾸先,我们创建dev分⽀,然后切换到dev分⽀: $ git checkout -b dev Switched to a new branch 'dev' git checkout命令加上 -b参数表⽰创建并切换,相当于以下两条命令: $ git branch dev $ git checkout dev Switched to branch 'dev' 然后,⽤ git branch命令查看当前分⽀: $ git branch * dev master git branch命令会列出所有分⽀,当前分⽀前⾯会标⼀个*号。 然后,我们就可以在dev分⽀上正常提交,⽐如对readme.txt做个修改,加上⼀⾏: Creating a new branch is quick. 然后提交: $ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test 1 file changed, 1 insertion(+) 现在,dev分⽀的⼯作完成,我们就可以切换回master分⽀: $ git checkout master Switched to branch 'master' 切换回master分⽀后,再查看⼀个readme.txt⽂件,刚才添加的内容不⻅了!因为那个提 交是在dev分⽀上,⽽master分⽀此刻的提交点并没有变: Git教程 By 廖雪峰 整理、排版: numbbbbb 现在,我们把dev分⽀的⼯作成果合并到master分⽀上: $ git merge dev Updating d17efd8..fec145a Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+) git merge命令⽤于合并指定分⽀到当前分⽀。合并后,再查看readme.txt的内容,就可以 看到,和dev分⽀的最新提交是完全⼀样的。 注意到上⾯的 Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把 master指向dev的当前提交,所以合并速度⾮常快。 当然,也不是每次合并都能 Fast-forward,我们后⾯会将其他⽅式的合并。 合并完成后,就可以放⼼地删除dev分⽀了: $ git branch -d dev Deleted branch dev (was fec145a). 删除后,查看branch,就只剩下master分⽀了: $ git branch * master 因为创建、合并和删除分⽀⾮常快,所以Git⿎励你使⽤分⽀完成某个任务,合并后再删掉 分⽀,这和直接在master分⽀上⼯作效果是⼀样的,但过程更安全。 ⼩结 Git⿎励⼤量使⽤分⽀: 查看分⽀:git branch 创建分⽀:git branch name 切换分⽀:git checkout name Git教程 By 廖雪峰 整理、排版: numbbbbb 创建+切换分⽀: git checkout -b name 合并某分⽀到当前分⽀: git merge name 删除分⽀: git branch -d name Git教程 By 廖雪峰 整理、排版: numbbbbb 解决冲突 ⼈⽣不如意之事⼗之⼋九,合并分⽀往往也不是⼀帆⻛顺的。 准备新的feature1分⽀,继续我们的新分⽀开发: $ git checkout -b feature1 Switched to a new branch 'feature1' 修改readme.txt最后⼀⾏,改为: Creating a new branch is quick AND simple. 在feature1分⽀上提交: $ git add readme.txt $ git commit -m "AND simple" [feature1 75a857c] 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. Git还会⾃动提⽰我们当前master分⽀⽐远程的master分⽀要超前1个提交。 在master分⽀上把readme.txt⽂件的最后⼀⾏改为: Creating a new branch is quick & simple. 提交: $ git add readme.txt $ git commit -m "& simple" [master 400b400] & simple 1 file changed, 1 insertion(+), 1 deletion(-) 现在,master分⽀和feature1分⽀各⾃都分别有新的提交,变成了这样: Git教程 By 廖雪峰 整理、排版: numbbbbb 这种情况下,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. # # Unmerged paths: # (use "git add/rm ..." as appropriate 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 distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. <<<<<<< HEAD Creating a new branch is quick & simple. ======= Creating a new branch is quick AND simple. Git教程 By 廖雪峰 整理、排版: numbbbbb >>>>>>> feature1 Git⽤<<<<<<<,=======,>>>>>>>标记出不同分⽀的内容,我们修改如下后保存: Creating a new branch is quick and simple. 再提交: $ git add readme.txt $ git commit -m "conflict fixed" [master 59bc1cb] conflict fixed 现在,master分⽀和feature1分⽀变成了下图所⽰: ⽤带参数的 git log也可以看到分⽀的合并情况: $ git log --graph --pretty=oneline --abbrev-commit * 59bc1cb conflict fixed |\ | * 75a857c AND simple * | 400b400 & simple |/ * fec145a branch test ... 现在,删除feature1分⽀: $ git branch -d feature1 Deleted branch feature1 (was 75a857c). ⼯作完成。 ⼩结 当Git⽆法⾃动合并分⽀时,就必须⾸先解决冲突。解决冲突后,再提交,合并完成。 Git教程 By 廖雪峰 整理、排版: numbbbbb ⽤ git log --graph命令可以看到分⽀合并图。 Git教程 By 廖雪峰 整理、排版: numbbbbb 分⽀管理策略 通常,合并分⽀时,如果可能,Git会⽤“Fast forward”模式,但这种模式下,删除分⽀ 后,会丢掉分⽀信息。 如果要强制禁⽤“Fast forward”模式,Git就会在merge时⽣成⼀个新的commit,这 样,从分⽀历史上就可以看出分⽀信息。 下⾯我们实战⼀下 --no-ff⽅式的merge: ⾸先,仍然创建并切换dev分⽀: $ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt⽂件,并提交⼀个新的commit: $ git add readme.txt $ git commit -m "add merge" [dev 6224937] add merge 1 file changed, 1 insertion(+) 现在,我们切换回master: $ git checkout master Switched to branch 'master' 准备合并dev分⽀,请注意 --no-ff参数,表⽰禁⽤“Fast forward”: $ git merge --no-ff -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 --abbrev-commit * 7825a50 merge with no-ff |\ | * 6224937 add merge |/ * 59bc1cb conflict fixed ... 可以看到,不使⽤“Fast forward”模式,merge后就像这样: Git教程 By 廖雪峰 整理、排版: numbbbbb 分⽀策略 在实际开发中,我们应该按照⼏个基本原则进⾏分⽀管理: ⾸先,master分⽀应该是⾮常稳定的,也就是仅⽤来发布新版本,平时不能在上⾯干活; 那在哪干活呢?干活都在dev分⽀上,也就是说,dev分⽀是不稳定的,到某个时候,⽐如 1.0版本发布时,再把dev分⽀合并到master上,在master分⽀发布1.0版本; 你和你的⼩伙伴们每个⼈都在dev分⽀上干活,每个⼈都有⾃⼰的分⽀,时不时地往dev分 ⽀上合并就可以了。 所以,团队合作的分⽀看起来就像这样: ⼩结 Git分⽀⼗分强⼤,在团队开发中应该充分应⽤。 合并分⽀时,加上 --no-ff参数就可以⽤普通模式合并,合并后的历史有分⽀,能看出来曾经 做过合并,⽽ fast forward合并就看不出来曾经做过合并。 Git教程 By 廖雪峰 整理、排版: numbbbbb Bug分⽀ 软件开发中,bug就像家常便饭⼀样。有了bug就需要修复,在Git中,由于分⽀是如此的 强⼤,所以,每个bug都可以通过⼀个新的临时分⽀来修复,修复后,合并分⽀,然后将临 时分⽀删除。 当你接到⼀个修复⼀个代号101的bug的任务时,很⾃然地,你想创建⼀个分⽀issue -101来 修复它,但是,等等,当前正在dev上进⾏的⼯作还没有提交: $ git status # On branch dev # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # new file: hello.py # # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: readme.txt # 并不是你不想提交,⽽是⼯作只进⾏到⼀半,还没法提交,预计完成还需1天时间。但是, 必须在两个⼩时内修复该bug,怎么办? 幸好,Git还提供了⼀个stash功能,可以把当前⼯作现场“储藏”起来,等以后恢复现场后 继续⼯作: $ git stash Saved working directory and index state WIP on dev: 6224937 add merge HEAD is now at 6224937 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. $ git checkout -b issue-101 Switched to a new branch 'issue-101' 现在修复bug,需要把“Git is free software ...”改为“Git is a free software ...”,然后 提交: $ git add readme.txt $ git commit -m "fix bug 101" [issue-101 cc17032] fix bug 101 Git教程 By 廖雪峰 整理、排版: numbbbbb 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 2 commits. $ git merge --no-ff -m "merged bug fix 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 cc17032). 太棒了,原计划两个⼩时的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: 6224937 add merge ⼯作现场还在,Git把stash内容存在某个地⽅了,但是需要恢复⼀下,有两个办法: ⼀是⽤ 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 ..." to unstage) # # new file: hello.py # # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: readme.txt # Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40) 再⽤ git stash list查看,就看不到任何stash内容了: Git教程 By 廖雪峰 整理、排版: numbbbbb $ git stash list 你可以多次stash,恢复的时候,先⽤ git stash list查看,然后恢复指定的stash,⽤命令: $ git stash apply stash@{0} ⼩结 修复bug时,我们会通过创建新的bug分⽀进⾏修复,然后合并,最后删除; 当⼿头⼯作没有完成时,先把⼯作现场 git stash⼀下,然后去修复bug,修复后,再 git stash pop,回到⼯作现场。 Git教程 By 廖雪峰 整理、排版: numbbbbb 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 ..." to unstage) # # new file: vulcan.py # $ git add vulcan.py $ git commit -m "add feature vulcan" [feature-vulcan 756d4af] add feature vulcan 1 file changed, 2 insertions(+) create mode 100644 vulcan.py 切回dev,准备合并: $ git checkout 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友情提醒,feature-vulcan分⽀还没有被合并,如果删除,将丢失掉修改, 如果要强⾏删除,需要使⽤命令 git branch -D feature-vulcan。 现在我们强⾏删除: $ git branch -D feature-vulcan Git教程 By 廖雪峰 整理、排版: numbbbbb Deleted branch feature-vulcan (was 756d4af). 终于删除成功! ⼩结 开发⼀个新feature,最好新建⼀个分⽀; 如果要丢弃⼀个没有被合并过的分⽀,可以通过 git branch -D name强⾏删除。 Git教程 By 廖雪峰 整理、排版: numbbbbb 多⼈协作 当你从远程仓库克隆时,实际上Git⾃动把本地的master分⽀和远程的master分⽀对应起来 了,并且,远程仓库的默认名称是origin。 要查看远程库的信息,⽤ git remote: $ git remote origin 或者,⽤ git remote -v显⽰更详细的信息: $ git remote -v origin git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/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:michaelliao/learngit.git Cloning into 'learngit'... remote: Counting objects: 46, done. remote: Compressing objects: 100% (26/26), done. remote: Total 46 (delta 16), reused 45 (delta 15) Git教程 By 廖雪峰 整理、排版: numbbbbb Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done. Resolving deltas: 100% (16/16), done. 当你的⼩伙伴从远程库clone时,默认情况下,你的⼩伙伴只能看到本地的master分⽀。不 信可以⽤ git branch命令看看: $ git branch * master 现在,你的⼩伙伴要在dev分⽀上开发,就必须创建远程origin的dev分⽀到本地,于是他 ⽤这个命令创建本地dev分⽀: $ git checkout -b dev origin/dev 现在,他就可以在dev上继续修改,然后,时不时地把dev分⽀push到远程: $ git commit -m "add /usr/bin/env" [dev 291bea8] add /usr/bin/env 1 file changed, 1 insertion(+) $ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 349 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git fc38031..291bea8 dev -> dev 你的⼩伙伴已经向origin/dev分⽀推送了他的提交,⽽碰巧你也对同样的⽂件作了修改,并 试图推送: $ git add hello.py $ git commit -m "add coding: utf-8" [dev bd6ae48] add coding: utf-8 1 file changed, 1 insertion(+) $ git push origin dev To git@github.com:michaelliao/learngit.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to 'git@github.com:michaelliao/ learngit.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 推送失败,因为你的⼩伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单, Git已经提⽰我们,先⽤ git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解 决冲突,再推送: $ git pull Git教程 By 廖雪峰 整理、排版: numbbbbb remote: Counting objects: 5, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From github.com:michaelliao/learngit fc38031..291bea8 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 If you wish to set tracking information for this branch you can do so with: git branch --set-upstream dev origin/ git pull也失败了,原因是没有指定本地dev分⽀与远程origin/dev分⽀的链接,根据提⽰, 设置dev和origin/dev的链接: $ git branch --set-upstream dev origin/dev Branch dev set up to track remote branch dev from origin. 再pull: $ git pull Auto-merging hello.py CONFLICT (content): Merge conflict in hello.py Automatic merge failed; fix conflicts and then commit the result. 这回 git pull成功,但是合并有冲突,需要⼿动解决,解决的⽅法和分⽀管理中的 解决冲突 完 全⼀样。解决后,提交,再push: $ git commit -m "merge & fix hello.py" [dev adca45d] merge & fix hello.py $ git push origin dev Counting objects: 10, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 747 bytes, done. Total 6 (delta 0), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git 291bea8..adca45d dev -> dev 因此,多⼈协作的⼯作模式通常是这样: 1. ⾸先,可以试图⽤ git push origin branch-name推送⾃⼰的修改; 2. 如果推送失败,则因为远程分⽀⽐你的本地更新,需要先⽤ git pull试图合并; 3. 如果合并有冲突,则解决冲突,并在本地提交; 4. 没有冲突或者解决掉冲突后,再⽤ git push origin branch-name推送就能成功! Git教程 By 廖雪峰 整理、排版: numbbbbb 如果 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 branch-name origin/branch-name; • 从远程抓取分⽀,使⽤ git pull,如果有冲突,要先处理冲突。 Git教程 By 廖雪峰 整理、排版: numbbbbb 标签管理 发布⼀个版本时,我们通常先在版本库中打⼀个标签,这样,就唯⼀确定了打标签时刻的版 本。将来⽆论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。 所以,标签也是版本库的⼀个快照。 Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分⽀很像对不 对?但是分⽀可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。 Git教程 By 廖雪峰 整理、排版: numbbbbb 创建标签 在Git中打标签⾮常简单,⾸先,切换到需要打标签的分⽀上: $ git branch * dev master $ git checkout master Switched to branch 'master' 然后,敲命令 git tag name就可以打⼀个新标签: $ git tag v1.0 可以⽤命令 git tag查看所有标签: $ git tag v1.0 默认标签是打在最新提交的commit上的。有时候,如果忘了打标签,⽐如,现在已经是周 五了,但应该在周⼀打的标签没有打,怎么办? ⽅法是找到历史提交的commit id,然后打上就可以了: $ git log --pretty=oneline --abbrev-commit 6a5819e merged bug fix 101 cc17032 fix bug 101 7825a50 merge with no-ff 6224937 add merge 59bc1cb conflict fixed 400b400 & simple 75a857c AND simple fec145a branch test d17efd8 remove test.txt ... ⽐⽅说要对“add merge”这次提交打标签,它对应的commit id是“6224937”,敲⼊ 命令: $ git tag v0.9 6224937 再⽤命令 git tag查看标签: $ git tag v0.9 v1.0 注意,标签不是按时间顺序列出,⽽是按字⺟排序的。可以⽤ git show tagname查看标签信 息: $ git show v0.9 commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4 Author: Michael Liao Git教程 By 廖雪峰 整理、排版: numbbbbb Date: Thu Aug 22 11:22:08 2013 +0800 add merge ... 可以看到,“v0.9”确实打在“add merge”这次提交上。 还可以创建带有说明的标签,⽤-a指定标签名,-m指定说明⽂字: $ git tag -a v0.1 -m "version 0.1 released" 3628164 ⽤命令 git show tagname可以看到说明⽂字: $ git show v0.1 tag v0.1 Tagger: Michael Liao Date: Mon Aug 26 07:28:11 2013 +0800 version 0.1 released commit 3628164fb26d48395383f8f31179f24e0882e1e0 Author: Michael Liao Date: Tue Aug 20 15:11:49 2013 +0800 append GPL ... 还可以通过-s⽤私钥签名⼀个标签: $ git tag -s v0.2 -m "signed version 0.2 released" fec145a 签名采⽤PGP签名,因此,必须⾸先安装gpg(GnuPG),如果没有找到gpg,或者没有 gpg密钥对,就会报错: gpg: signing failed: secret key not available error: gpg failed to sign the data error: unable to sign the tag 如果报错,请参考GnuPG帮助⽂档配置Key。 ⽤命令 git show tagname可以看到PGP签名信息: $ git show v0.2 tag v0.2 Tagger: Michael Liao Date: Mon Aug 26 07:28:33 2013 +0800 signed version 0.2 released -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iQEcBAABAgAGBQJSGpMhAAoJEPUxHyDAhBpT4QQIAKeHfR3bo... -----END PGP SIGNATURE----- Git教程 By 廖雪峰 整理、排版: numbbbbb commit fec145accd63cdc9ed95a2f557ea0658a2a6537f Author: Michael Liao Date: Thu Aug 22 10:37:30 2013 +0800 branch test ... ⽤PGP签名的标签是不可伪造的,因为可以验证PGP签名。验证签名的⽅法⽐较复杂,这⾥ 就不介绍了。 ⼩结 • 命令 git tag name⽤于新建⼀个标签,默认为HEAD,也可以指定⼀个commit id; • -a tagname -m "blablabla..."可以指定标签信息; • -s tagname -m "blablabla..."可以⽤PGP签名标签; • 命令 git tag可以查看所有标签; Git教程 By 廖雪峰 整理、排版: numbbbbb 操作标签 如果标签打错了,也可以删除: $ git tag -d v0.1 Deleted tag 'v0.1' (was e078af9) 因为创建的标签都只存储在本地,不会⾃动推送到远程。所以,打错的标签可以在本地安全 删除。 如果要推送某个标签到远程,使⽤命令 git push origin tagname: $ git push origin v1.0 Total 0 (delta 0), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git * [new tag] v1.0 -> v1.0 或者,⼀次性推送全部尚未推送到远程的本地标签: $ git push origin --tags Counting objects: 1, done. Writing objects: 100% (1/1), 554 bytes, done. Total 1 (delta 0), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git * [new tag] v0.2 -> v0.2 * [new tag] v0.9 -> v0.9 如果标签已经推送到远程,要删除远程标签就⿇烦⼀点,先从本地删除: $ git tag -d v0.9 Deleted tag 'v0.9' (was 6224937) 然后,从远程删除。删除命令也是push,但是格式如下: $ git push origin :refs/tags/v0.9 To git@github.com:michaelliao/learngit.git - [deleted] v0.9 要看看是否真的从远程库删除了标签,可以登陆GitHub查看。 ⼩结 • 命令 git push origin tagname可以推送⼀个本地标签; • 命令 git push origin --tags可以推送全部未推送过的本地标签; • 命令 git tag -d tagname可以删除⼀个本地标签; • 命令 git push origin :refs/tags/tagname可以删除⼀个远程标签。 Git教程 By 廖雪峰 整理、排版: numbbbbb 使⽤ GitHub 我们⼀直⽤GitHub作为免费的远程仓库,如果是个⼈的开源项⺫,放到GitHub上是完全没 有问题的。其实GitHub还是⼀个开源协作社区,通过GitHub,既可以让别⼈参与你的开源 项⺫,也可以参与别⼈的开源项⺫。 在GitHub出现以前,开源项⺫开源容易,但让⼲⼤⼈民群众参与进来⽐较困难,因为要参 与,就要提交代码,⽽给每个想提交代码的群众都开⼀个账号那是不现实的,因此,群众也 仅限于报个bug,即使能改掉bug,也只能把diff⽂件⽤邮件发过去,很不⽅便。 但是在GitHub上,利⽤Git极其强⼤的克隆和分⽀功能,⼈们群众真正可以第⼀次⾃由参与 各种开源项⺫了。 如何参与⼀个开源项⺫呢?⽐如⼈⽓极⾼的bootstrap项⺫,这是⼀个⾮常强⼤的CSS框 架,你可以访问它的项⺫主⻚ https://github.com/twbs/bootstrap,点“Fork”就在⾃⼰ 的账号下克隆了⼀个bootstrap仓库,然后,从⾃⼰的账号下clone: git clone git@github.com:michaelliao/bootstrap.git ⼀定要从⾃⼰的账号下clone仓库,这样你才能推送修改。如果从bootstrap的作者的仓库 地址 git@github.com:twbs/bootstrap.git克隆,因为没有权限,你将不能推送修改。 Bootstrap的官⽅仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap,以及你 ⾃⼰克隆到本地电脑的仓库,他们的关系就像下图显⽰的那样: 如果你想修复bootstrap的⼀个bug,或者新增⼀个功能,⽴刻就可以开始干活,干完后, 往⾃⼰的仓库推送。 如果你希望bootstrap的官⽅库能接受你的修改,你就可以在GitHub上发起⼀个pull request。当然,对⽅是否接受你的pull request就不⼀定了。 如果你没能⼒修改bootstrap,但⼜想要试⼀把pull request,那就Fork⼀下我的仓库: https://github.com/michaelliao/learngit,创建⼀个your-github-id.txt的⽂本⽂件,写 点⾃⼰学习Git的⼼得,然后推送⼀个pull request给我,我会视⼼情⽽定是否接受。 ⼩结 • 在GitHub上,可以任意Fork开源仓库; • ⾃⼰拥有Fork后的仓库的读写权限; • 可以推送pull request给官⽅仓库来贡献代码。 Git教程 By 廖雪峰 整理、排版: numbbbbb ⾃定义 Git 在 安装Git ⼀节中,我们已经配置了user.name和user.email,实际上,Git还有很多可配置 项。 ⽐如,让Git显⽰颜⾊,会让命令输出看起来更醒⺫: $ git config --global color.ui true 这样,Git会适当地显⽰不同的颜⾊,⽐如 git status命令: ⽂件名就会标上颜⾊。 我们在后⾯还会介绍如何更好地配置Git,以便让你的⼯作更⾼效。 Git教程 By 廖雪峰 整理、排版: numbbbbb 忽略特殊⽂件 有些时候,你必须把某些⽂件放到Git⼯作⺫录中,但⼜不能提交它们,⽐如保存了数据库 密码的配置⽂件啦,等等,每次 git status都会显⽰“Untracked files ...”,有强迫症的童 鞋⼼⾥肯定不爽。 好在Git考虑到了⼤家的感受,这个问题解决起来也很简单,在Git⼯作区的根⺫录下创建⼀ 个特殊的 .gitignore⽂件,然后把要忽略的⽂件名填进去,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 Git教程 By 廖雪峰 整理、排版: numbbbbb # My configurations: db.ini deploy_key_rsa 最后⼀步就是把 .gitignore也提交到Git,就完成了!当然检验 .gitignore的标准是 git status 命令是不是说“working directory clean”。 使⽤Windows的童鞋注意了,如果你在资源管理器⾥新建⼀个.gitignore⽂件,它会⾮常弱 智地提⽰你必须输⼊⽂件名,但是在⽂本编辑器⾥“保存”或者“另存为”就可以把⽂件保 存为.gitignore了。 ⼩结 1. 忽略某些⽂件时,需要编写 .gitignore。 2. .gitignore⽂件本⾝要放到版本库⾥,并且可以对 .gitignore做版本管理! Git教程 By 廖雪峰 整理、排版: numbbbbb 配置别名 有没有经常敲错命令?⽐如 git status? status这个单词真⼼不好记。 如果敲 git st就表⽰ git status那就简单多了,当然这种偷懒的办法我们是极⼒赞成的。 我们只需要敲⼀⾏命令,告诉Git,以后 st就表⽰ status: $ git config --global alias.st status 好了,现在敲 git st看看效果。 当然还有别的命令可以简写,很多⼈都⽤ co表⽰ checkout, ci表⽰ commit, br表⽰ branch: $ git config --global alias.co checkout $ git config --global alias.ci commit $ git config --global alias.br branch 以后提交就可以简写成: $ git ci -m "bala bala bala..." --global参数是全局参数,也就是这些命令在这台电脑的所有Git仓库下都有⽤。 在 撤销修改 ⼀节中,我们知道,命令 git reset HEAD file可以把暂存区的修改撤销掉 (unstage),重新放回⼯作区。既然是⼀个unstage操作,就可以配置⼀个unstage别 名: $ git config --global alias.unstage 'reset HEAD' 当你敲⼊命令: $ git unstage test.py 实际上Git执⾏的是: $ git reset HEAD test.py 配置⼀个 git last,让其显⽰最后⼀次提交信息: $ git config --global alias.last 'log -1' 这样,⽤ git last就能显⽰最近⼀次的提交: $ git last commit adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2 Merge: bd6ae48 291bea8 Author: Michael Liao Date: Thu Aug 22 22:49:22 2013 +0800 merge & fix hello.py Git教程 By 廖雪峰 整理、排版: numbbbbb 甚⾄还有⼈丧⼼病狂地把 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 lg的效果: 为什么不早点告诉我?别激动,咱不是为了多记⼏个英⽂单词嘛! ⼩结 给Git配置好别名,就可以输⼊命令时偷个懒。我们⿎励偷懒。 Git教程 By 廖雪峰 整理、排版: numbbbbb 搭建 Git服务器 在 远程仓库 ⼀节中,我们讲了远程仓库实际上和本地仓库没啥不同,纯粹为了7x24⼩时开 机并交换⼤家的修改。 GitHub就是⼀个免费托管开源代码的远程仓库。但是对于某些视源代码如⽣命的商业公司 来说,既不想公开源代码,⼜舍不得给GitHub交保护费,那就只能⾃⼰搭建⼀台Git服务器 作为私有仓库使⽤。 搭建Git服务器需要准备⼀台运⾏Linux的机器,强烈推荐⽤Ubuntu或Debian,这样,通过 ⼏条简单的apt命令就可以完成安装。 假设你已经有sudo权限的⽤户账号,下⾯,正式开始安装。 第⼀步,安装git: $ sudo apt-get install git 第⼆步,创建⼀个git⽤户,⽤来运⾏git服务: $ sudo adduser git 第三步,创建证书登录: 收集所有需要登录的⽤户的公钥,就是他们⾃⼰的id_rsa.pub⽂件,把所有公钥导⼊到 / home/git/.ssh/authorized_keys⽂件⾥,⼀⾏⼀个。 第四步,初始化Git仓库: 先选定⼀个⺫录作为Git仓库,假定是/srv/sample.git,在/srv⺫录下输⼊命令: $ sudo git init --bare sample.git Git就会创建⼀个裸仓库,裸仓库没有⼯作区,因为服务器上的Git仓库纯粹是为了共享,所 以不让⽤户直接登录到服务器上去改⼯作区,并且服务器上的Git仓库通常都以.git结尾。然 后,把owner改为git: $ sudo chown -R git:git sample.git 第五步,禁⽤shell登录: 出于安全考虑,第⼆步创建的git⽤户不允许登录shell,这可以通过编辑/etc/passwd⽂件 完成。找到类似下⾯的⼀⾏: git:x:1001:1001:,,,:/home/git:/bin/bash 改为: git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell 这样,git⽤户可以正常通过ssh使⽤git,但⽆法登录shell,因为我们为git⽤户指定的git- shell每次⼀登录就⾃动退出。 第六步,克隆远程仓库: 现在,可以通过 git clone命令克隆远程仓库了,在各⾃的电脑上运⾏: Git教程 By 廖雪峰 整理、排版: numbbbbb $ git clone git@server:/srv/sample.git Cloning into 'sample'... warning: You appear to have cloned an empty repository. 剩下的推送就简单了。 管理公钥 如果团队很⼩,把每个⼈的公钥收集起来放到服务器的 /home/git/.ssh/authorized_keys ⽂件⾥就是可⾏的。如果团队有⼏百号⼈,就没法这么玩了,这时,可以⽤ Gitosis来管理公 钥。 这⾥我们不介绍怎么玩 Gitosis了,⼏百号⼈的团队基本都在500强了,相信找个⾼⽔平的 Linux管理员问题不⼤。 管理权限 有很多不但视源代码如⽣命,⽽且视员⼯为窃贼的公司,会在版本控制系统⾥设置⼀套完善 的权限控制,每个⼈是否有读写权限会精确到每个分⽀甚⾄每个⺫ 录下。因为Git是为Linux 源代码托管⽽开发的,所以Git也继承了开源社区的精神,不⽀持权限控制。不过,因为Git ⽀持钩⼦(hook),所以, 可以在服务器端编写⼀系列脚本来控制提交等操作,达到权限 控制的⺫的。 Gitolite就是这个⼯具。 这⾥我们也不介绍 Gitolite了,不要把有限的⽣命浪费到权限⽃争中。 ⼩结 搭建Git服务器⾮常简单,通常10分钟即可完成; 要⽅便管理公钥,⽤ Gitosis; 要像SVN那样变态地控制权限,⽤ Gitolite。 Git教程 By 廖雪峰 整理、排版: numbbbbb 期末总结 终于到了期末总结的时刻了! 经过⼏天的学习,相信你对Git已经初步掌握。⼀开始,可能觉得Git上⼿⽐较困难,尤其是 已经熟悉SVN的童鞋,没关系,多操练⼏次,就会越⽤越顺⼿。 Git虽然极其强⼤,命令繁多,但常⽤的就那么⼗来个,掌握好这⼗⼏个常⽤命令,你已经 可以得⼼应⼿地使⽤Git了。 友情附赠国外⺴友制作的Git Cheat Sheet,建议打印出来备⽤: Git Cheat Sheet 现在告诉你Git的官⽅⺴站: http://git-scm.com,英⽂⾃我感觉不错的童鞋,可以经常去 官⺴看看。什么,打不开⺴站?相信我,我给出的绝对是官⺴地址,⽽且,Git官⺴决没有 那么容易宕机,可能是你的⼈品问题,赶紧⾯壁思过,好好想想原因。 如果你学了Git后,⼯作效率⼤增,有更多的空闲时间健⾝看电影,那我的教学⺫标就达到 了。 谢谢观看! Git教程 By 廖雪峰 整理、排版: numbbbbb
还剩76页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

ka520

贡献于2015-11-05

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf