Git的学习与使用

Git

Git概念

Git是一个免费的，开源的分布式版本控制系统，可以快速高效的处理从小型到大型的项目。

什么是版本控制

版本控制是一种记录一个或者若干个文件内容变化，以便将来查阅特定版本修订情况的系统。
解释一下啥意思：

比如我今天写了一个登录功能，然后这可能是01版本，然后明天呢我把这个登录功能做了一个优化，升级成了02版本，，后天可能还会优化形成第三个03版本，所以在开发中项目每次迭代时都会产生一个新的版本，当我们发现某一个版本出现bug时，就需要回退到上一个没有bug的版本，但是这么多个迭代版本，我们肯定是需要一个版本管理工具来替我们管理这些版本的。
Git做的就是这么个事情。

软件开发中采用版本控制系统是个明智的选择。
有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。
就算你乱来一气把整个项目的文件改的改删的删，你也可以照样轻松恢复到原先的样子，但同时呢额外增加的工作量却微乎其微，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致bug出现的原因，又是谁在何时报告了某个功能缺陷等等。

版本控制系统的分类

集中化的版本控制系统

分布式的版本控制系统

由于上面集中化版本控制系统的那些缺点，于是分布式版本控制系统问世了。
在这类系统中，像Git、BitKeeper等，客户端并不只是提取最新版本的文件快照，而是把代码仓库完整的镜像下来。

更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。这样，你就可以在同一个项目中分别和不同工作小组的人相互协作。

分布式的版本控制系统在管理项目时存放的不是项目版本与版本之间的差异，它存的是索引（所需磁盘空间很小所以每个客户端都可以放下整个项目的历史记录）。

Git简史

这个人缔造了Linux内核，他热衷于开源是真正的大神级别的程序员，当时Linux也是因为不停迭代所以产生了很多的版本号，一开始他们（众多开源者共同开发维护）采用的也是集中式的版本控制工具，到了后来还是决定采用分布式的会更舒服，于是Bitkeeper找上了门，觉得Linux如果发布在Bitjeeper上那简直就是打了一波完美广告，可是他们是商业项目，Bitkeeper不开源，于是开发Linux的这群人就想瞄一瞄人家的源码，被Bitkeeper发现之后就终止合作了，于是又是林纳斯，直接花了一周的时间开发出了Git，一个月之后就将Linux部署在了Git上，同样是开源免费的，于是Git现在就这么火爆了，当然会火也并非单纯的是因为免费，是因为其具有独特的优势，具体Git好在哪里后面会说。

Git下载与安装

首先去官网下载Windows版本：

下载完之后，就直接双击安装包安装即可：

GNU协议，直接next：

安装位置，选择好就next：

从上到下解释一下：

Additional icons on the desktop：是否创建者桌面快捷方式。

Windows Explorer integration（Git Bash Here、Git GUI Here）：是否将Git功能集成到Windows鼠标的右键（这个一定要选上，进入Git直接鼠标右击即可）。

Git LFS: 是否支持Git大文件，默认选中

Assocsiate.git*… : 打开Git文件默认使用的文本编辑器

Assocsiate.sh files… ：是否让Git能够打开.sh文件结尾的文件

其他的没什么好说的了， 这个页面我们就选择其默认选中的就可以了。

点击next：

给这个程序起一个名字，默认Git，点击next：

选择默认的文本编辑器，不用改，直接用Vim就可以，点击next：

这个页面的意思它要根据你的不同选择去适应你的path环境变量，我们一般选第一个是最安全的，因为选第一个的话它的path环境变量不会变，点击next：

选择一个本地库与远程库的连接方式，我们一般都用第一个OpenSSL，点击next：

选择行末的一个换行符的转换方式，我们默认选择第一个就行，点击next：

选择终端，选第一个，因为Git我们都用的linux命令，不会让它和windows的终端命令混合用，所以选第一个Git自带的终端就行，点击next：

这两个默认勾上的是，第一个是启动文件系统的缓存，第二个是启动Git的授权管理器，就选这两个就行，点击install安装：

第一个框框问你是否要运行Git Bash，第二个问你是否要查看文档进度，都可以不选，点击next，至此就安装成功了已经。

现在我们直接在桌面上点击鼠标右键就可以看到Git了：

点击Git Bash：

就会出现上面的黑乎乎窗口，这就是Git的终端，以后我们就会在这里面录入一些命令，这些命令和Linux都是通用的命令。

Git结构

本地结构

本地结构其实就是三个区域，工作区、暂存区和本地库。

工作区其实就是我们写代码的地方，我们写的文件都放在这个工作区里。

暂存区就是我们打算要提交的东西但是又还没有提交，这些东西就放在暂存区里，在将来我们可以将这里面的内容提交到本地库或者撤回到工作区。

本地库里面存储的就是真正的每个历史版本的信息。

然后这三个区域如何关联呢？就是上面图中的两个命令。

代码托管中心_本地库和远程库的交互方式

代码托管中心是干嘛的

它的任务是帮我们远程维护远程库。

本地库和远程库的交互方式有两种：
（1） 团队内部协作

（2）跨团队协作

托管中心种类

局域网环境下：可以搭建GitLab服务器作为代码托管中心，GitLab可以自己去创建。

外网环境下：可以由GitLab或者Gitee作为代码托管中心，GitHub或者Gitee是现成的托管中心，不用自己去创建。

初始化本地仓库

步骤如下;

1、创建一个文件夹

2、打开Git终端（右键点击Git Bash Here）

进入以后可点击鼠标右键打开里面的options，设置字体和一些样式，我这里只修改终端大小：

在Git中命令和Linux是一样的，毕竟都是同一个人写的嘛…

查看Git的版本：

清屏：

设置签名：

签名的作用是用来确定本次提交的东西是谁提交上来的，这样以后追责才能确定是谁。

设置用户名和邮箱：
有global是设置全局的用户名：

设置全局的邮箱：

但即使是做了上述的操作，我们的本地仓库和我们的Git还是没有关系呀，因为我们现在才开始来对这个仓库进行初始化…

本地仓库初始化

首先进入我们刚刚创建的本地仓库，用cd命令切换文件目录（和linux中的一样）：

可以看见我们已经切换到了我们的目标文件位置。
然后输入下面的命令进行初始化：

那个.git文件是隐藏的，所以我们在改文件夹下看不见这个.git文件：
不过我们可以使用ll -la命令进行查看：

或者也可以在windows中将隐藏项目手动给展示出来：

然后我们就可以看见了：

我们也可以进入这个.git文件，看看这里面有什么：

看一下，还记得吧应该？每个文件前面的前缀如果是"-"则表示是一个文件，如果是"d"则表示的是一个文件夹。
然后上图中我们可以看到有一个config文件，后期我们的一些配置信息全部都是放在这个config下面的。还有一点要注意，这个.git文件里面的所有东西都不要乱动和改，否则这个仓库就用不了了。

常用命令

add：提交只暂存区命令、commit：提交至工作区命令

add为添加文件；

commit为提交文件。

演示：
我们现在我们刚刚创建的本地仓库GitResp中写一个Demo.txt文件：

这个文件虽然现在已经放在了我们的本地仓库里，但是这个文件实际上和我们的本地仓库是没有关系的，我们需要为其创建联系（回顾一下）：

现在我们将文件提交到暂存区（用add命令）：

注意命令操作一定要在本地仓库的目录中进行！！！否则就会报我上面一开始的错误。
然后现在我们将暂存区中的Demo.txt文件提交到本地仓库中（用commit命令）：

对上面的commit命令信息那一行的参数做一些解释：

-m：这是message的简写，表示信息，即表示后面的双引号中我们写的注释信息

双引号中的内容：我们针对本次提交做的一些注释

最后的Demo.txt：我们要提交的是哪个文件

只有使用commit命令操作之后才是真正的让文件受我们的Git管理了。

总结一下：

（1）不放在本地仓库里的文件，git是不进行管理的
（2）即使放在本地仓库的文件，git也不管理，除非已经通过add，commit命令操作之后git才会进行管理

status：查看文件所处位置状态命令

这命令干啥用的呢？

刚刚我们已经介绍过了add和commit命令，但是举个例子，就拿刚刚我们提交的Demo.txt文件来说，我们已经提交到本地仓库中了，可是如果过了一段时间再回来想看该文件时，我们很可能会忘记此时的Demo.txt文化是个什么状态了（是在暂存区还是本地仓库区？），所以此时我们就需要status命令来查看当前的文件所处的位置状态。

即：git status 看的是工作区和暂存区的状态。

演示：

解释一下：

On branch master: 分支和主干，后面会讲的。

nothing to commit：这很好解释了，说明当前的暂存区中没有文件需要commit。
我们可以测试一下，比如现在我们在GitResp下面创建一个新的文件叫Demo02.txt：

然后我们查看一下状态：

注意那句：Untracked files，没有被追踪到的文件，其实可以理解为没有被Git管理到的文件，然后下面用红色字体特意给我们标出来了是哪个文件没被管理到，就是我们刚刚新建的Demo02.txt。然后它下面也说了嘛，我们可以use “git add” to trace，就是可以用add命令对该文件进行追踪。

现在我们将其add进暂存区：

Demo02.txt文件变绿了看见没，说明此时它是在暂存区中的。
现在我们将其commit进我们的本地库：

1 file changed，0 insertions(+), 0 deletions(-)：啥意思，很明显嘛，这是我们第一次进行该文件的提交，我们也没有修改文件里面的内容，所以自然是0添加和0减少啊。
现在再查看status：

又和开始的一样啦，因为暂存区里没有任何东西。
现在我们修改一下Demo02.txt里面的内容：

再去查看对应的状态：

看见那行红字了吗，modified：Demo02.txt，它的意思是这个文件是被修改过了的，我们需要通过add命令重新将其提交至暂存区：

然后查看状态：

变绿啦。现在我们再将其提交到本地仓库中：

看见了吧。3 insertions，因为我们插入了三条语句。

log：查看版本历史命令

git log可以让我们查看以前提交的所有文件版本，显示从最近到最远的日志。
毕竟以后会用到版本的前进和后退，这个命令就可以让我们直观的找到以前的版本。

演示：

呐，这是我们之前的三次提交记录，得解释一波上面的东西。

commit后面的那一串长字符串：

这是当前历史记录的索引，索引与其对应的内容被记录为一对KV键值对，其中Key键就是索引，Value值对应的就是历史记录对应的具体内容。

显示内容：

从上到下，最上面的是最近的一次提交记录，最下面的是最远距离的提交记录。
另外每一条记录都包含了Author作者，也就是该次的提交者是谁；作者名后面是邮箱；Date后面记录的就是提交的日期，然后显示的下面的中文内容很眼熟是吧？那就是我们之前提交时写的注释。

log：查看版本历史命令再解析

当历史记录过多查看日志的时候，Git会有分页效果，因为一页展示不下：

在每一页的最下面会有个冒号（上面红框中的内容），在冒号这里输入对应的命令会有对应的提示：

下一页：空格
上一页：b
到尾页了，显示END：

退出：q

但是日志的展示方式呢也不止上面这一种，还有几种：
方式一: git log —> 分页方式（就我们上面讲的那种）。
方式二： git log --pretty=oneline(按行显示，页面对应的内容在上面讲过啦):

方式三：git log --oneline（只取索引号前七位）：

方式四：git reflog：

这个方式就比之前的方式多了中间那一列，HEAD@后面对应的{1}、{2}…其实就单纯表示了你要回退到该提交记录需要几步，1就是1步，9就是需要9步。

reset：前进后退版本命令

reset命令可以前进或者后退历史版本。
我们现在创建一个Test文件夹，第一次由空文件把内容修改为aaa，然后第二次把内容为aaa修改为aaa、bbb，第三次把内容修改为aaa、bbb、ccc，中间我们省略提交步骤（不可能到这儿了都还不会吧？）。
现在查看一下历史：

可以看见我们的HEAD指针此刻指向的是0位置，也就是我们最近一次提交的文件位置，看一下内容：

现在我们使用reset命令回退到注释为第二次提交的Test.txt文件内容的地方：
（使用git reset --hard 索引号），索引号可以鼠标选择（不用点击复制，它自己会复制，在Git终端中选择就是复制）然后之后右键选择paste粘贴在git reset --hard后面就可以，看了日志表我们知道注释为第二次提交的Test.txt文件的索引号为d7020bf：

现在我们再去看一下我们的Test.txt文件可以发现内容以及回退到了我们第二次提交时的样子了：

现在再看一下日志：

可以看见HEAD头指针已经指向到了我们的第二次提交Test.txt位置了。

reset的hard、mixed、soft参数

git reset --hard [索引]：
本地库的指针移动的同时，暂存区和工作区也同时跟着改变：

mixed参数（较少使用）：
本地库的指针移动的同时，暂存区跟着动而工作区不动：

soft参数：
本地库的指针移动的同时，暂存区和工作区都不动：

总结：以后用的多的肯定是第一种hard参数。

rm：删除文件命令

我们新建一个Test2文件，并将其add、commit进本地仓库，然后我们将其在工作区（就是我们的GitResp文件目录）删除，当然我们也可以直接在GitResp里面删，不过最好还是会使用命令来继续删除会好一点：

现在我们删除它：

可以看见GitResp里面就没有这个Test2文件了：

但是我们的暂存区里面其实还是存在我们刚刚删除的Test2.txt文件的，所以现在我们要去把暂存区中的Test2.txt删掉：
因为我们刚刚已经删除掉了，所以现在的git add Test2.txt操作就是把删除Test2.txt的操作同步到暂存区中去：

但是同样的，我们的工作区中也还是存在Test2.txt文件的，我们可以看一下本地库中是否存在：

可以看到第一个记录就是，所以也要同步删除：

现在再查看本地库中的日志：

但其实并不是真正的物理删除，因为你其实还是可以回到原来删除前的状态，因为我们的每一次操作都会被记录下来然后可以通过reset命令重新回退到该次操作版本的。

我们可以试一下，找回本地库中删除的文件，实际上就是将历史版本切换到刚才添加的那个版本即可：

因为用的是hard参数，所以可以看到工作区中也出现了Test2.txt文件：

找回暂存区中的数据

比如以下情景：
我们先删除了Test2.txt，然后同步到了暂存区，将暂存区中的Test2.txt文件也删除了：

可是我们到这里就后悔了，不想删除了想恢复暂存区中的数据Test.txt咋办？
其实和上面的做法一样，就是回退到删除之前的操作就可以了，我们看一下日志：

虽然它已经在了我们原来的位置，但我们只要让它再次指向一下原来的位置就可以恢复暂存区中的数据，当然工作区也恢复了该数据：

diff：比对两个文件之间差异的命令

先创建一个一个Test3.txt文件，并写上内容aaa：

现在我们将其提交到本地库中：

然后我们现在更改工作区中的内容，增加bbb：

现在就会产生一个问题，工作区和暂存区中的内容不一样，那么我们想看一下这两个地方的Test3.txt文件之间有什么不一样则可以使用我们的diff命令：

总结：git diff [文件名] --》》将工作区中的文件和暂存区中的文件进行比较。

如果是多个文件的比对，那么直接使用git diff就可以了，不需要加文件名：

总结：git diff ----》》 比较工作区中和暂存区中所有文件的差异。

那比较暂存区和工作区中差别呢？
使用：git diff [历史版本索引号] [文件名]

上面的HEAD就是最近那一次的指针嘛，当然也可以用索引号表示啦。

分支

什么是分支

在版本控制中，使用多条线同时推进多个任务。这里面说的多条线就是多个分支。
现在也可以解决我们之前遗留的问题：

看见上面红框中的On branch master了吗，其实它告诉我们的是就是我们现在位于主干（master）上。

下面用图示来解释什么是分支：

再来总结一下分支的好处：

同时多个分支可以并行开发，互相不耽误，互相不影响，提高开发效率。
如果有一个分支功能开发失败，那么直接删除这个分支就可以了，不会对其他分支产生任何影响。

查看、创建以及切换分支的操作

我们先创建一个文件叫Test4.txt，然后内容写上abc，然后提交至本地仓库中：

查看状态可以知道我们现在位于主分支上，并且主分支上已经没有需要提交的东西了。

查看分支git branch -v

现在我们还没有创建过分支，我们先查看一下有没有分支叭：

可以看见当前内部只有master一个主干分支，我们可以加上-v查看所有分支的最新版本：

可以看见这是我们刚刚在主干分支上提交的Test4.txt。

创建分支git branch [新的分支名]

用该命令即可创建一个新的分支：

然后可以查看一下现在内部的所有分支情况：

可以看见现在有两个分支了，一个是新建的分支一个是master主干分支，而且它们当前的最新版本都是我们刚刚添加的Test4.txt的版本。我们之前说过，一个新的分支被创建它就会自动复制一份当前主干分支上的最新版本进行复制。
同时我们还可以看见，上图中在master前有一个星号，这表示我们当前处于master主干分支上。

切换分支git checkout [所要切换的分支名]

现在我们切换到branch01分支：

然后现在我们再看一下所有分支的状态：

可以看见，现在我们就位于branch01分支上了。

分支冲突的问题及解决

现在我们将Test4.txt的内容再加上一段话：

然后我们将其添加到本地仓库：

然后我们再切换回主分支：

可以看见主分支上的当前版本号和我们的branch01分支截然不同了对叭，互不影响的。
我们再修改一下Test4.txt内容将其提交到master主分支的本地仓库中去：


现在再次切换到branch01分支上进行查看：

我们还可以看看我们的branch01分支下Test4.txt文件的内容：

切换回master查看Test4.txt内容：

可以看见主干与分支彼此之间互不影响。

主分支与分支的合并

现在我们将branch01分支合并到主分支：
1、首先进入主分支：

2、将branch01中的内容和主分支内容进行合并
使用git merge [要合并的分支名]

它提示了我们文件有冲突，通过之前的学习我们也知道，branch01里的Test4.txt文件的内容与master里的是不一样的。

我们接下来解决这种冲突，其实也很好解决，既然有两种方式，我们选一种留下来就行了。
比如我们现在只打算留下branch01中Test4.txt的内容，那就将master中Test4.txt的内容删掉：

然后我们重新将其提交至暂存区中：

然后进行commit操作，将其提交到本地仓库中：
这里要记住最后不要像之前commit的那样带文件名：

到这儿Git的操作就差不多讲完啦！