- Git简介
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的特点
- 集中式VS分布式
- 集中式版本控制系统
- 集中式VS分布式
集中化的版本控制系统( Centralized Version Control Systems,简称 CVCS )。这类系统,诸如 CVS,Subversion 以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法(见下图1)。
这种系统最显而易见的缺点是中央服务器的单点故障。如果宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。要是中央服务器的磁盘发生故障,碰巧没做备份,或者备份不够及时,就会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录,而被客户端偶然提取出来的保存在本地的某些快照数据就成了恢复数据的希望。但这样的话依然是个问题,你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存在类似问题,只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新记录的风险。
-
-
- 分布式版本控制系统
-
分布式版本控制系统( Distributed Version Control System,简称 DVCS )会把服务器上的代码仓库完整地镜像下来。这样每个人的电脑上都有一份完成的服务器代码仓库的镜像,任何一处协同工作用的服务器发生故障,事后都可以用个人的电脑上的像出来的本地仓库恢复。因为每一次的提取操作,实际上都是一次对代码仓库的完整备份(见下图2)。我们可以看到电脑A与电脑B与服务器上的版本内容完全一致
-
- 版本存储方式的差异
- 直接记录快照,而非差异比较
- 版本存储方式的差异
Git 和其他版本控制系统的主要差别在于,Git 只关心文件数据的整体是否发生变化,而大多数其他系统则只关心文件内容的具体差异。这类系统(CVS,Subversion,Perforce,Bazaar 等等)每次记录有哪些文件作了更新,以及都更新了哪些行的什么内容,请看下图。
其他系统在每个版本中记录着各个文件的具体差异
Git 并不保存这些前后变化的差异数据。实际上,Git 更像是把变化的文件作快照后,记录在一个微型的文件系统中。每次提交更新时,它会纵览一遍所有文件的指纹信息并对文件作一快照,然后保存一个指向这次快照的索引。为提高性能,若文件没有变化,Git 不会再次保存,而只对上次保存的快照作一链接。Git 的工作方式就像图 4 所示。
Git 保存每次更新时的文件快照
-
- 近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源,不用连网。但如果用 CVCS 的话,差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新,所以处理起来速度飞快。
举个例子,如果要浏览项目的历史更新摘要,Git 不用跑到外面的服务器上去取数据回来,而直接从本地数据库读取后展示给你看。所以任何时候你都可以马上翻阅,无需等待。如果想要看当前版本的文件和一个月前的版本之间有何差异,Git 会取出一个月前的快照和当前文件作一次差异运算,而不用请求远程服务器来做这件事,或是把老版本的文件拉到本地来作比较。
用 CVCS 的话,没有网络或者断开 VPN 你就无法做任何事情。但用 Git 的话,就算你在飞机或者火车上,都可以非常愉快地频繁提交更新,等到了有网络的时候再上传到远程仓库。同样,在回家的路上,不用连接 VPN 你也可以继续工作。换作其他版本控制系统,这么做几乎不可能,抑或非常麻烦。比如 Perforce,如果不连到服务器,几乎什么都做不了(译注:默认无法发出命令 p4 edit file 开始编辑文件,因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文件权限可以绕过这个限制,只是完成后还是无法提交更新。);如果是 Subversion 或 CVS,虽然可以编辑文件,但无法提交更新,因为数据库在网络上。看上去好像这些都不是什么大问题,但实际体验过之后,你就会惊喜地发现,这其实是会带来很大不同的。
- Git的安装
Git支持Linux、Windows和Mac系统,安装Git,可以到Git官方网站直接下载安装程序。
- Git仓库的基本概念和流程
什么是版本库?版本库又名仓库,英文名repository,你可以简单的理解一个目录,这个目录里面的所有文件都可以被Git管理起来,每个文件的修改,删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻还可以将文件”还原”。
-
- git仓库的基本概念
- 远程仓库(Remote):
也叫作资源库,是远程机器上的代码库,用于做不同版本库文件交换更新。如Gitlab,GitHub,gitee。
- 本地库(Repository):
是用户在本地创建的目录,拥有远程库的一个快照,由工作区和版本库构成。
- 工作区(Workspace):
本地库的根目录中除.git目录以外的内容,存储内容的实际文件。
- 暂存区(stage/Index):
也叫做缓存区,暂存信息存放在.git目录"下的index文件(.git/index)中,用于临时保存内容的修改;
- 版本库(.git目录)
是本地库的根目录中的一个隐藏目录.git,用于记录版本信息,Git进行版本控制所需要的文件,则都放在.git文件夹中;
- 分支(Branch):
本地库中默认创建一个主(master)分支,分支意味着你可以从开发主线上分离开来,然后在不影响主线的同时继续工作。
本地库和远程库的关系
开发人员通过Git命令来管理代码,最常用的6个命令如下图所示:
-
- git仓库的工作流程
从一般开发者的角度来看,使用Git的工作流程是:
- 克隆远程库:从远程库上克隆完整的Git仓库(包括代码和版本信息)到本地;
- 在本地库上修改代码:在本地库上根据不同的开发目的,创建分支,修改代码;
- 提交到分支:在本地分支上提交代码;
- 把修改合并到本地主分支:在本地库上提交更新,也就是说,把修改合并到本地主分支;
- 把远程库合并到本地主分支:把远程库上的最新代码fetch下来,跟本地主分支合并,如果存在冲突,那么解决冲突。
- 把本地主分支提交到远程库:生成补丁(patch),把补丁发送给远程库。
- Git的命令
- 创建版本库
创建一个版本库也非常简单,如下我是D盘下 目录下新建一个testGit版本库。
右键通过命令行的方式打开窗口
pwd 命令是用于显示当前的目录。
通过命令 git init 把这个目录变成git可以管理的仓库,如下
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。
这时候你当前testgit目录下会多了一个.git的目录,这个目录是Git来跟踪管理版本的,没事千万不要手动乱改这个目录里面的文件,否则,会把git仓库给破坏了。.git里面内容如下:
-
- 添加文件和修改提交文件
首先要明确下,所有的版本控制系统,只能跟踪文本文件的改动,比如txt文件,网页,所有程序的代码等,Git也不列外,版本控制系统可以告诉你每次的改动,但是图片,视频这些二进制文件,虽能也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是知道图片从1kb变成2kb,但是到底改了啥,版本控制也不知道。
- 创建文件readme.txt, 此刻文件在工作区(WorkSpace)
通过git status可以查看文件追踪的情况
- 使用命令 git add readme.txt添加到暂存区里面去。
我们发现添加到暂存区的时候会有警告出现。不过没关系,是换行符的警告。
我们可以看到readme.txt目前处于暂存区。
如果要提交多个文件
我们可以在add后面指定文件的列表
git add test2.txt test3.txt
如果想要添加工作区所有文件到暂存区
git add .
我们可以通过提示的话来撤销回工作区
git rm --cached readme.txt
- 提交文件到主分支
git commit -m 'first commit'
现在我们已经提交了一个readme.txt文件了,我们下面可以通过命令git status来查看是否还有文件未提交
注意:注释是必须要写的。
- 修改文件,在文件中加入一行。查看git的状态
我们发现文件进入到工作区
最新版本改成了
git restore test3.txt
此刻我们发现界面上有两个提示:
-
- 提交修改后的文件
-
- 通过checkout上一个版本的文件来覆盖修改后的文件
git checkout -- readme.txt
注意 :--后面要有空格
-
- 版本回退
- 1.日志查看
- 版本回退
现在我已经对readme.txt文件做了三次修改了,那么我现在想查看下历史记录,如何查呢?我们现在可以使用命令 git log 演示如下所演示
git log
git log命令显示从最近到最远的显示日志,我们可以看到最近三次提交
如果嫌上面显示的信息太多的话,我们可以使用命令 git log pretty=oneline 演示如下:
-
-
- 版本回退和撤销
-
- 版本回退
现在我想使用版本回退操作,我想把当前的版本回退到上一个版本,要使用什么命令呢?可以使用如下2种命令,第一种是:git reset --hard HEAD^ 那么如果要回退到上上个版本只需把HEAD^ 改成 HEAD^^ 以此类推。那如果要回退到前100个版本的话,使用上面的方法肯定不方便,我们可以使用下面的简便命令操作:git reset --hard HEAD~100 即可。未回退之前的readme.txt内容如下:
我们查看文件的内容:
查看提交日志:
同时我们也可以通过sha1的前四位来做回退
git reset –heard sha1
- 回退撤销
我们看到 增加update 2内容我们没有看到了,但是现在我想回退到最新的版本,如:有update 2的内容要如何恢复呢?我们可以通过版本号回退,使用命令方法如下:
git reset --hard 版本号 ,但是现在的问题假如我已经关掉过一次命令行或者update 2内容的版本号我并不知道呢?要如何知道增加update 2内容的版本号呢?可以通过如下命令即可获取到版本号:git reflog 演示如下:
git reflog
通过上面的显示我们可以知道,增加内容update 2的版本号是 8d95a43.我们现在可以命令
git reset --hard 8d95a43
查看撤销后的结果。
-
- 删除文件
添加并且提交了多个文件
一般情况下,可以直接在文件目录中把文件删了,或者使用如上rm命令:rm b.txt ,如果我想彻底从版本库中删掉了此文件的话,可以再执行commit命令 提交掉。
git rm test.txt
我们发现删除的文件直接进入暂存区(此刻需要注意,如果使用rm删除不在暂存区,需要git add才会进入暂存区。如果进入暂存区可以退回工作区,使用下面命令 git reset HEAD test.txt
),
提交之后文件被删除。
-
- Git配置信息Config
- config概述
- Git配置信息Config
在git中,我们使用git config 命令用来配置git的配置文件,git配置级别主要有以下3类:
1、仓库级别 local 【优先级最高】
2、用户级别 global【优先级次之】
3、系统级别 system【优先级最低】
git 仓库级别对应的配置文件是当前仓库下的.git/config
git 用户级别对应的配置文件是用户宿主目录下的~/.gitconfig
git系统级别对应的配置文件是git安装目录下的 /etc/gitconfig
当然我们可以在cmd命令提示符中输入以下查看配置信息
git config --local -l
git config --global -l
git config --system -l
-
-
- config修改
-
演示修改用户名和邮箱:
git config --global user.name "renliang"
git config --global user.email "renliang@126.com"
注意不要手动修改 每个级别的配置文件,要用命令。
对于git来说,配置文件的权重是仓库>全局>系统。Git会使用这一系列的配置文件来存储你定义的偏好,它首先会查找/etc/gitconfig文件(系统级),该文件含有对系统上所有用户及他们所拥有的仓库都生效的配置值。接下来Git会查找每个用户的~/.gitconfig文件(全局级)。最后Git会查找由用户定义的各个库中Git目录下的配置文件.git/config(仓库级),该文件中的值只对当前所属仓库有效。
- .gitignore文件
在项目中,我们可能一起提交多个文件
· git add -A 提交所有变化
· git add -u 提交被修改(modified)和被删除(deleted)文件,不包括新文件(new)
· git add . 提交新文件(new)和被修改(modified)文件,不包括被删除(deleted)文件
在使用git的过程中,一般我们总会有些文件无需纳入git的管理,也不希望它们总出现在未跟踪文件列表,这些文件通常是日志文件、临时文件、编译产生的中间文件、工具自动生成的文件等等。
此时我们可以创建一个名为 .gitignore 的文件,列出要忽略的文件模式,Git会根据这些模式规则来判断是否将文件添加到版本控制中。
注意:在windows下可以创建文件名为.gitignore.,保存之后系统会自动重命名为 .gitignore
-
- 格式规范
(1)所有空行或者以注释符号 # 开头的行都会被 Git 忽略
(2)可以使用标准的 glob 模式匹配
(3)匹配模式最后跟斜杠(/)说明要忽略的是目录
(4)要忽略指定模式以外的文件或目录,可以在模式前加上感叹号(!)进行取反
-
- glob模式
所谓的 glob 模式是指 shell 所使用的简化了的正则表达式,匹配规则如下:
"*":星号匹配零个或多个任意字符
[]:匹配任何一个列在方括号中的字符,如[ab]匹配a或者匹配b
"?":问号匹配一个任意字符
[n-m]:匹配所有在这两个字符范围内的字符,如[0-9]表示匹配所有0到9的数字
匹配示例
logs/: 忽略当前路径下的logs目录,包含logs下的所有子目录和文件
/logs.txt: 忽略根目录下的logs.txt文件
*.class: 忽略所有后缀为.class的文件
!/classes/a.class:不忽略classes目录下的a.class文件
tmp/*.txt: 只忽略tmp目录下的.txt文件
**/foo: 可以忽略/foo, a/foo, a/b/foo等
-
- 案例使用
1. 在需要创建 .gitignore 文件的文件夹, 右键选择Git Bash 进入命令行,进入项目所在目录。
2. 输入 touch .gitignore 在文件夹就生成了一个“.gitignore”文件
3.然后用编辑器打开这个文件进行编辑就行了。
4.然后就写规则来操作要忽略的文件了。
.gitignore内容
创建两个文件
查看状态我们发现testclass.class不在工作区
提交也不会进入暂存区
-
- 定义全局的.gitignore
除了可以在项目中定义.gitignore文件外,还可以设置全局的.gitignore文件来管理所有Git项目的行为。
这种方式在不同的项目开发者之间是不共享的,是属于项目之上Git应用级别的行为。
可以在任意目录下创建相应的.gitignore文件,然后再使用以下命令配置Git
git config --global core.excludesfile ~/.gitignore
-
- .gitignore规则不生效
.gitignore只能忽略那些原来没有被track的文件,如果某些文件已经被纳入了版本管理中,则修改.gitignore是无效的。所以一定要养成在项目开始就创建.gitignore文件的习惯。
-
- java开发通用模板
#java
*.class
#package file
*.war
*.ear
*.zip
*.tar.gz
*.rar
#maven ignore
target/
build/
#eclipse ignore
.settings/
.project
.classpatch
#Intellij idea
.idea/
/idea/
*.ipr
*.iml
*.iws
# temp file
*.log
*.cache
*.diff
*.patch
*.tmp
# system ignore
.DS_Store
Thumbs.db
接下来我想看下readme.txt文件到底改了什么内容,如何查看呢?可以使用如下命令:
-
- diff命令
git diff readme.txt
diff里面a表示前面那个变量,b表示第二个变量
HEAD commit版本
Index staged版本
- 工作目录 vs 暂存区
$ git diff <filename>
意义:查看文件在工作目录与暂存区的差别。如果还没 add 进暂存区,则查看文件自身修改前后的差别。也可查看和另一分支的区别。
$ git diff <branch> <filename>
- 暂存区 vs Git仓库
git diff --cached <filename>
意义:表示查看已经 add 进暂存区但是尚未 commit 的内容同最新一次 commit 时的内容的差异。 也可以指定仓库版本:
git diff --cached <commit> <filename>
- 工作目录 vs Git仓库
git diff <commit> <filename>
意义:查看工作目录同Git仓库指定 commit 的内容的差异。
<commit>=HEAD 时:查看工作目录同最近一次 commit 的内容的差异。
- Git仓库 vs Git仓库
git diff <commit> <commit>
意义:Git仓库任意两次 commit 之间的差别。
以上命令可以不指定 <filename>,则对全部文件操作。
以上命令涉及和 Git仓库 对比的,均可指定 commit 的版本。
HEAD 最近一次 commit
HEAD^ 上次提交
HEAD~100 上100次提交
- Git分支管理
Git 的默认分支就是 master。你所作的commit会在master分支上自动移动。 在多次提交操作之后,master分支指向最后那个commit object(提交对象链)。
Git 的 “master” 分支并特殊,跟其它分支没有区别。 之所以几乎每一个仓库都有 master 分支,是因为 git init 命令默认创建它。
但很多时候听别人说master分支,往往有一种 这个分支是稳定、无bug的分支。而develop往往预示这新功能,不稳定的分支。这和分支策略有关,但本质上这两个分支没区别。
-
- 分支创建
通过git branch来查看和创建分支。
创建标签记在HEAD指针所指向的提交点创建tag(就是当前所在分支)
git branch dev
分支切换到dev
git checkout dev
创建分支与切换分支同时完成
git checkout -b dev2
这是我们在dev2分支创建一个文件A.txt并且提交。我们发现在dev2分支可以看到这个文件,当我们切换会master时候无法看到这个文件。
-
- 分支删除
- 不能删除自己所在的分支
我们可以切换到master删除一个合并后的或者没有发生变化的分支
- 如果一个分支发生了变化不能删除
我们发现dev2发生了变化,同时没有合并不能删除。如果要强制删除可以
git branch -D dev2
-
- 分支合并
我们继续基于上面的例子,切换到master上做dev2 的合并
我们发现master分支上也添加了A.txt这个文件
如果修改的是同一个文件也可以做同样的合并,让我们切换到dev2分支修改A.txt中的内容。在A.txt中添加了一行World
我们切换会master分支的时候发现提示了A.txt的变动。通过合并发现master分支上也合并了dev2修改的内容,合并之后dev2就删除就被允许了
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/bian-cheng-ri-ji/5884.html