廖雪峰老师的Git教程之前看过一遍,讲的很简单基础明了,入门应该是够了的,之后对Git的使用还是比较少,所以很多命令都忘记了,前阵子刚刚入门ctf(很弱很弱很弱的那种)有做到git泄露的题目,觉得有必要再了解一遍Git,所以这两天再看了一遍书,做一下笔记,方便查阅,但感觉还是要用起来,用起来,用起来才能记住,本文也只当做学习记录了。注意,本文略长且无营养,阅读请考虑仔细!!!
先罗列一下Git常用的指令
1 | git init //将本地目录初始化为可管理的仓库 |
1 Git简介
Git是目前世界上最先进的分布式版本控制系统。(没有之一!!!)
关于分布式版本控制系统,廖雪峰老师是这样描述
简而言之,我的理解大概就是用于多人协作开发项目(或修改文件),并且每次都能记录文件的改动。
2 安装(略)
网上教程很多
3 一些基本操作
创建版本库
创建一个版本库首先选一个合适的地方,创建一个空目录,右键点击git bash,在打开的命令行界面内,依次输入下面指令
1 | mkdir dir1 //新建dir1 |
完成后文件夹是这个样子,尽量目录中不要出现中文,不然可能会报一些奇怪的错误
一下是一些命令:
git init
执行初始化命令将该目录变成Git可以管理的仓库,注意,命令的执行是要在该dir1目录下的,如果不是要先cd到 zz/dir1下在执行初始化语句
1 | git init |
1 | Initialized empty Git repository in 路径 //就算成功 |
成功后可以在dir1的目录下找到这个.git文件,看不到的可能要勾选一下文件夹隐藏的项目
.git文件是Git来跟踪管理版本库的,一般不要手动修改这个目录里的文件,否则会破坏仓库
git add
添加文件到版本库
在dir1目录下新建一个test.txt,执行即添加成功
1 | git add test.txt |
git commit
git commit命令,-m后面输入的是本次提交的说明,可以输入任意的内容,但最好是有意义的,这样你在之后能从历史记录里面可以根据commit看到每次修改的地方是什么,很方便。
1 | git commit -m "wrote a test.txt file" |
git commit命令执行成功后悔提示你,哪个文件被改动了,具体改动了什么。
为什么Git添加要分add,commit两步?
因为可以执行多条add后,一次性commit提交。例如以下命令:
1 | git add test1.txt |
git status
git status命令可以随时掌握工作区(后面会提到)的当前状态
如当我们新建test文件,执行完git add git commit命令后,执行git status,会提示我们
add 和 commit都已经完成了,工作目录是干净的。
git diff
我们对test.txt文件进行了修改,但是隔了一段时间忘记了修改了什么内容,这时候我们就可以执行
1 | git diff "test.txt" |
这样就可以看到修改了什么内容了,确认修改无误后,提交到我们的仓库即可,提交修改和提交文件是一样的。执行以下两条指令即可
1 | git add test.txt |
git diff一般配合git status使用,git status显示有文件被修改过,就可以用git diff查看修改内容。
版本回退
1 | git log //查看历史记录 |
git log命令显示从最近到最远的提交日志,可以看到3次提交,简单查看也可以执行:
1 | git log --pretty=oneline |
(HEAD-master)表示的是当前的版本,前面黄颜色的一大串字符串表示一个版本ID Commit ID
后面信息的表示版本修改了什么内容。
现在要将版本回退到上一个版本,也就是**”change the test.txt"的版本,我们可以执行git reset**命令,如下
1 | git reset --hard HEAD^ //此命令表示回退到前一个版本 |
还可以执行:
1 | git reset --hard e71f58 |
后面的e71f58正是**“change the test.txt"**版本的版本号,不需要写全版本号,前几位就可以了(但为了防止多个版本号前几位相同导致冲突,尽量多写几位)
Git版本回退的实现原理是Git在内部有个指向当前版本的指针HEAD,当回退版本时,仅仅是将HEAD的指向改变而已。
git reflog命令
1 | git reflog |
用来记录每次命令的命令,可以实现**“穿梭未来**,如廖老师所讲:
4 工作区,暂存区和版本库
工作区 Working Directory:就是在电脑里能看到的目录,比如前面的dir1文件夹就是一个工作区,也是我们直接添加和编辑文件的地方。
暂存区 Stage 或 Index 数据暂时存放的区域,可在工作区和版本库之间进行数据的友好交流。当我们执行**git add **时,实际上就是把工作区的文件修改添加到暂存区。
版本库 Repository:工作区有一个隐藏目录.git,这个文件夹不算工作者,而算Git的版本库,当我们执行完git commit,实际上就是把暂存区的所有内容一次性提交到当前分支。
三个分区的关系如图:
在我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,commit就是往master分支上提交我们的修改。
简单理解,就是执行完一个add,或连续完多个add,就是将修改文件添加到暂存区,然后执行一次commit就可以将暂存区的修改文件一次提交到版本库。
5 管理修改
Git之所以比其他的版本控制系统更流行更好的原因,是因为**Git跟踪并管理的是修改,而非文件。**意思就是每次修改文件或新建文件,如果不执行add到暂存区,执行commit时是不会被加入到版本库中的。
撤销修改
1 | git checkout -- test.txt |
撤销总结:
6 删除文件
一般我们通常都会在文件管理器中删除掉文件,这样只是删除掉工作区的文件,那我们的版本库中还存在着这个文件,这时存在两种情况,第一是我们确实想要删除这个文件,并把该文件从版本库中删除,此时我们可以执行下面两条命令完成版本库中文件的删除。
1 | git rm test.txt |
另一种情况是我们删错了,不要慌,此时版本库中还有该文件,我们可以执行一键还原我们的文件
1 | git checkout -- test.txt |
7 远程仓库
Github相当于提供一个Git服务器,提供Git仓库托管服务,不同位置的多台主机可以从Github上面下载版本库,实现多人协作开发。
(1)添加远程库
首先在Github新建一个仓库,与本地一个已有的本地仓库关联,在本地的仓库下运行命令
1 | git remote add origin https://github.com/Github账户/Github仓库名.git |
远程库的名字为origin,这也是Git的默认叫法。
(2)把本地库的所有内容推送到远程库上
1 | git push -u origin master |
实际上是把当前分支master推送到远程,由于远程库是空的,第一次推送master分支时,加上了参数-u,Git不但会把本地的master分支内容推送到远程新的master分支,还会把本地的master分支和远程的master分支关联起来,以后的推送或者拉取时就可以简化命令。
从此以后,只要本地作了提交,只需执行
1 | git push origin master |
就可以把本地master分支的最新修改推至Github。
(3)从远程库克隆
从现有的远程库,新建一个目录,将远程库克隆到我们一个本地库
1 | git clone https://github.com/Github账户/Github仓库名.git |
8 分支管理
创建分支,执行以下命令:
1 | git branch dev //新建branch分支 |
查看分支情况
1 | git branch |
将分支dev合并到当前分支上(一般是合并到master分支上,所以要先切换到master分支)
1 | git merge dev |
合并完就可以删除分支
1 | git branch -d dev |
解决冲突:廖老师讲得很清楚,直接抠图
9 保存现场
1 | git stash |
git stash可以把当前工作现场“储藏起来”,等以后恢复现场后再继续工作。执行完git stash后,工作区是干净的,因此可以做其他的修改和调整,调整完再还原原来的工作现场。
恢复现场可以有两个办法
1 | git stash apply //恢复后,stash内容并不删除,需要再执行 |
查看已保存的工作现场可以用以下指令
1 | git stash list |
丢弃一个没有被合并过的分支,要通过强制删除命令删除分支
1 | git branch -D name //name为分支名 |
10 多人协作
(1)查看远程库的信息
1 | git remote -v //查看远程库的信息,-v可选可不选 |
(2) 推送分支
推送分支,就是将该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样Git就会把该分支推送到远程库对应的远程分支上。
1 | git push origin master //推送master分支 |
(3)抓取分支
当你的同伴从远程库clone到本地时,默认情况下,只能看到本地的master分支。现在如果,你的同伴要在dev分支上开发,就必须创建远程origin的dev分支到本地,可以执行
1 | git checkout -b dev origin/dev |
这样,同伴就可以在dev继续修改,修改完将dev分支push到远程库。
考虑一种情况,你的同伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件进行了修改,并试图推送,这是推送失败,原因是你的小伙伴的最新提交和你试图推送的提交有冲突
怎么解决?先用git pull把最新的提交从origin/dev抓取下来,在本地合并,解决冲突,再推送。解决步骤命令如下:
1 | git branch --set-upstream dev origin/dev //指定本地dev分支与远程origin/dev分支的链接 |
11 标签管理
发布一个新版本时,我们可以在版本库先打一个标签,这样,就唯一确定了打标签时刻的版本,标签也是版本库的一个快照。
打标签时,切换到需要打标签的分支上,执行:
1 | git tag v1.0 //v1.0为标签 |
默认标签都是打在最新提交的commit上的,如果之前的版本忘记打标签了,现在要打标签,也有办法,首先要先执行git log查看历史提交的commit id,然后执行
1 | git tag v0.9 74645665 // 74645665为对应commit ID的前几位 |
还可以创建带有说明的标签,执行:
1 | git tag -a v0.1 -m "version 0.1 released" 3628164 //-a 指定标签名,-m 指定说明文字 |
想要查看具体某一个标签的信息,可以执行:
1 | git show v0.9 //显示标签v0.9的信息 |
可以用命令git tag查看所有标签
1 | git tag |
如果标签打错了,也可以删除 执行:
1 | git tag -d v0.1 |
因为创建的标签都只存储在本地,不会自动推送到远程,如果要推送某个标签到远程,可以执行:
1 | git push origin v1.0 |
如果标签已经推送到远程,要删除远程标签,就需要先从本地删除,再从远程删除,命令如下:
1 | git tag -d v0.9 //删除本地标签 |
写完才发现原来码了这么多,感觉还是有很多细节要注意,特别是pull,push等指令要配合起来使用,理解Git的工作原理就更为重要,还需再查阅更多资料,还有就是,要用起来,用起来,用起来。(可惜自己太菜了,没项目可以push到Gayhub)。
Hexo博客的基本前提按道理来说也是要懂得Git的使用,可hexo clean hexo g -d已经把Git细节给隐藏了。
…