学线移动例会:git
前言:为什么要有git与GitHub&Gitee
1.起源
很多人都知道,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了。
2.集中式与分布式
Linus一直痛恨的CVS及SVN都是集中式的版本控制系统,而Git是分布式版本控制系统,集中式和分布式版本控制系统有什么区别呢?
先说集中式版本控制系统,版本库是集中存放在中央服务器的,而干活的时候,用的都是自己的电脑,所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家自己改,改完了,再放回图书馆。
集中式版本控制系统最大的毛病就是必须联网才能工作,如果在局域网内还好,带宽够大,速度够快,可如果在互联网上,遇到网速慢的话,可能提交一个10M的文件就需要5分钟,这还不得把人给憋死啊。
那分布式版本控制系统与集中式版本控制系统有何不同呢?分布式版本控制系统根本没有“中央服务器”,每个人的电脑上都是一个完整的版本库,这样,你工作的时候,就不需要联网了,因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库,那多个人如何协作呢?比方说你在自己电脑上改了文件A,你的同事也在他的电脑上改了文件A,这时,你们俩之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。
和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了。
在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。
当然,Git的优势不单是不必联网这么简单,后面我们还会看到Git极其强大的分支管理,把SVN等远远抛在了后面。
CVS作为最早的开源而且免费的集中式版本控制系统,直到现在还有不少人在用。由于CVS自身设计的问题,会造成提交文件不完整,版本库莫名其妙损坏的情况。同样是开源而且免费的SVN修正了CVS的一些稳定性问题,是目前用得最多的集中式版本库控制系统。
除了免费的外,还有收费的集中式版本控制系统,比如IBM的ClearCase(以前是Rational公司的,被IBM收购了),特点是安装比Windows还大,运行比蜗牛还慢,能用ClearCase的一般是世界500强,他们有个共同的特点是财大气粗,或者人傻钱多。
微软自己也有一个集中式版本控制系统叫VSS,集成在Visual Studio中。由于其反人类的设计,连微软自己都不好意思用了。
分布式版本控制系统除了Git以及促使Git诞生的BitKeeper
外,还有类似Git的Mercurial和Bazaar等。这些分布式版本控制系统各有特点,但最快、最简单也最流行的依然是Git!
安装
首先,下载安装程序或者使用国内Windows镜像站
不出意外除了更改安装路径都是next,细节参考此博客
温馨提示:路径中尽量不要有英文名
基本概念
分支
分支是什么
分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习Git的时候,另一个你正在另一个平行宇宙里努力学习SVN。
如果两个平行宇宙互不干扰,那对现在的你也没啥影响。不过,在某个时间点,两个平行宇宙合并了,结果,你既学会了Git又学会了SVN!
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。(但其实通常并不这么做)
常见分支
一、主分支master
代码库应该有且只有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。
Git主分支的名字,默认叫做Master。它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发。
二、 开发分支Develop
主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop(或者Dev)。
这个分支可以用来生成代码的最新隔夜版本(nightly)。如果想正式对外发布,就在Master分支上,对Develop分支进行"合并"(merge)。
三、临时性分支
临时性分支主要有三种:
功能分支 (feature)
预发布分支 (release)
修补bug分支 (fixbug)
这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。
少用,就不再展开讲
工作区、暂存区、版本库
工作区(Working Directory)
就是你在电脑里能看到的目录。
版本库(Repository)
工作区有一个隐藏目录.git
,这个不算工作区,而是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master
,以及指向master
的一个指针叫HEAD
。
head就不细说了,参考:https://www.liaoxuefeng.com/wiki/896043488029600/900003767775424
我们把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用
git add
把文件添加进去,实际上就是把文件修改添加到暂存区;第二步是用
git commit
提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master
分支,所以,现在,git commit
就是往master
分支上提交更改。
你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
上手操作
创建版本库
1 | git init |
进行创建与提交
在此目录下新建learn.txt,输入任意字符,比如”我想学git“,执行:(添加)
1 | git add learn.txt |
就可以添加到仓库,Unix的哲学是“没有消息就是好消息”
我们新建类、接口等文件时,就往往执行add
不信?执行:(显示状态)
1 | git status |
会显示:
现在数据存储在暂存区
如何存入版本库?执行:(提交)
1 | git commit -m |
简单解释一下git commit
命令,-m
后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样你就能从历史记录里方便地找到改动记录。
嫌麻烦不想输入-m "xxx"
行不行?确实有办法可以这么干,但是强烈不建议你这么干,因为输入说明对自己对别人阅读都很重要。实在不想输入说明的童鞋请自行Google,我不告诉你这个参数。
git commit
命令执行成功后会告诉你,1 file changed
:1个文件被改动(我们新添加的learn.txt文件);1 insertions
:插入了一行内容(learn.txt有一行内容)。
此时,再查看状态:
可见,没什么可以提交的了。
注意:
Q:输入git add readme.txt
,得到错误:fatal: not a git repository (or any of the parent directories)
。
A:Git命令必须在Git仓库目录内执行(git init
除外),在仓库目录外执行是没有意义的。
回退
修改文件,再次提交。但是要先add,再commit。演示如下:
查看提交记录:
1 | git log |
如图:
像这样,你不断对文件进行修改,然后不断提交修改到版本库里,就好比打原神游戏时,每通关一部分就会与复苏之门建立联系,如果某一关没过去,你还可以选择读取前一关的状态再重新开始。Git也是一样,每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”,这个快照在Git中被称为commit
。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit
恢复,然后继续工作,而不是把几个月的工作成果全部丢失。
如何回退?执行:
1 | git reset --hard HEAD^ |
会显示回退到了上一版
不过回退的可选参数实在太多,不展开讲,可以参考菜鸟教程
以上都是一些基础性内容,并且实际操作中用的也不多,但是了解一下可以让大家对git的原理有更清楚的认识,接下来的部分是应用最频繁的
远程仓库
引言
一般来说,git的工作流程如下:
我们也知道Git 并不像 SVN 那样有个中心服务器。
目前我们使用到的 Git 命令都是在本地执行,如果你想通过 Git 分享你的代码或者与其他开发人员合作。 你就需要将数据放到一台其他开发人员能够连接的服务器上。
(注:首先确保学线gitlab账号已注册)
克隆
克隆一个远程项目
1 | git clone url |
比如:git clone http://git.swsdu.online/lzw-sdu/first-git-job.git
(可能要输账号密码)
你会发现文件夹里多了first-git-job这个文件夹,就是远程仓库中的项目内容
push&pull&merge
push
基础知识
git push
命令用于将本地分支的更新,推送到远程主机。
1 | git push <远程主机名> <本地分支名>:<远程分支名> |
注意,分支推送顺序的写法是<来源地>:<目的地>,所以git pull
是<远程分支>:<本地分支>,而git push
是<本地分支>:<远程分支>。(pull下面会说)
至于远程主机,可以用
git remote
查看,具体不展开讲,学线一般只有origin
如果省略远程分支名,则表示将本地分支推送与之存在"追踪关系"的远程分支(通常两者同名),如果该远程分支不存在,则会被新建。
1 | git push origin master |
上面命令表示,将本地的master
分支推送到origin
主机的master
分支。如果后者不存在,则会被新建。
如果省略本地分支名,则表示删除指定的远程分支,因为这等同于推送一个空的本地分支到远程分支。
1 | git push origin :master |
上面命令表示删除origin
主机的master
分支。
如果当前分支与远程分支之间存在追踪关系,则本地分支和远程分支都可以省略。
1 | git push origin |
上面命令表示,将当前分支推送到origin
主机的对应分支。
如果当前分支只有一个追踪分支,那么主机名都可以省略。
1 | git push |
如果当前分支与多个主机存在追踪关系,则可以使用-u
选项指定一个默认主机,这样后面就可以不加任何参数使用git push
。
1 | git push -u origin master |
上面命令将本地的master
分支推送到origin
主机,同时指定origin
为默认主机,后面就可以不加任何参数使用git push
了。
不带任何参数的git push
,默认只推送当前分支,这叫做simple方式。此外,还有一种matching方式,会推送所有有对应的远程分支的本地分支。Git 2.0版本之前,默认采用matching方法,现在改为默认采用simple方式。如果要修改这个设置,可以采用git config
命令。
1 | git config --global push.default matching |
还有一种情况,就是不管是否存在对应的远程分支,将本地的所有分支都推送到远程主机,这时需要使用--all
选项。
1 | git push --all origin |
上面命令表示,将所有本地分支都推送到origin
主机。
如果远程主机的版本比本地版本更新,推送时Git会报错,要求先在本地做git pull
合并差异,然后再推送到远程主机。这时,如果你一定要推送,可以使用--force
选项。
1 | git push --force origin |
上面命令使用--force
选项,结果导致远程主机上更新的版本被覆盖。除非你很确定要这样做,否则应该尽量避免使用--force
选项。
操作
在前面克隆到本地的库中,我们看到里面已经有.git
文件,我们在这个文件夹下进行操作。
添加自定义内容,然后push到远程仓库,注意要先add并提交到本地版本库。然后直接:
1 | git push |
因为本地跟远程都只有master分支,而且只有origin一个远程主机
pull
git pull
命令的作用是,取回远程主机某个分支的更新,再与本地的指定分支合并。它的完整格式稍稍有点复杂。
1 | git pull <远程主机名> <远程分支名>:<本地分支名> |
比如,取回origin
主机的next
分支,与本地的master
分支合并,需要写成下面这样。
1 | git pull origin next:master |
如果远程分支是与当前分支合并,则冒号后面的部分可以省略。
1 | git pull origin next |
上面命令表示,取回origin/next
分支,再与当前分支合并。实质上,这等同于先做git fetch
,再做git merge
。
1 | git fetch origin |
在某些场合,Git会自动在本地分支与远程分支之间,建立一种追踪关系(tracking)。比如,在git clone
的时候,所有本地分支默认与远程主机的同名分支,建立追踪关系,也就是说,本地的master
分支自动"追踪"origin/master
分支。
Git也允许手动建立追踪关系。
1 | git branch --set-upstream master origin/next |
上面命令指定master
分支追踪origin/next
分支。
如果当前分支与远程分支存在追踪关系,git pull
就可以省略远程分支名。
1 | git pull origin |
上面命令表示,本地的当前分支自动与对应的origin
主机"追踪分支"(remote-tracking branch)进行合并。
如果当前分支只有一个追踪分支,连远程主机名都可以省略。
1 | git pull |
上面命令表示,当前分支自动与唯一一个追踪分支进行合并。
如果合并需要采用rebase模式,可以使用--rebase
选项。
1 | git pull --rebase <远程主机名> <远程分支名>:<本地分支名> |
如果远程主机删除了某个分支,默认情况下,git pull
不会在拉取远程分支的时候,删除对应的本地分支。这是为了防止,由于其他人操作了远程主机,导致git pull
不知不觉删除了本地分支。
但是,你可以改变这个行为,加上参数 -p
就会在本地删除远程已经删除的分支。
1 | git pull -p |
merge
有时一个项目有多个开发者,如果你修改的文件在远程仓库中已经被其他开发者修改,当你想把自己的修改push到远程仓库或者从远程仓库更新代码时就会被提醒需要merge。当然merge的功能也不限于此,你还可以通过merge进行分支管理,当然这是后话。
一般来说我们的merge都是在IDE中进行的,此处以jetbrains家的IDE为例。
左边的Local Changes代表”当前“分支上的修改;
右边的Changes from Server代表“合并进来”的分支上的修改;
中间的Result代表经过处理后的最终内容;
这部分还是建议各部门结合自己IDE实际情况再说几句,这里不展开讲。
PS. SSH key
在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa
和id_rsa.pub
这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:
1 | $ ssh-keygen -t rsa -C "youremail@example.com" |
你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。
如果一切顺利的话,可以在用户主目录里找到.ssh
目录,里面有id_rsa
和id_rsa.pub
两个文件,这两个就是SSH Key的秘钥对,id_rsa
是私钥,不能泄露出去,id_rsa.pub
是公钥,可以放心地告诉任何人。
第2步:在“SSH Keys”页面,填上任意Title,在Key文本框里粘贴id_rsa.pub
文件的内容即可。
为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。
当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。
参考:
git的简介与概念、远程仓库等:廖雪峰的官方网站
git的常见分支:https://blog.csdn.net/zyw0713/article/details/80083431
git基本操作:廖雪峰官网(同上)与菜鸟教程
git push、pull的知识点:阮一峰的博客