Git 初识
不知道你工作或学习时，有没有遇到这样的情况：我们在编写各种文档时，为了防止文档丢失，更改失误，失误后能恢复到原来的版本，不得不复制出一个副本，比如：
"报告-v1"
"报告-v2"
"报告-v3"
"报告-确定版"
"报告-最终版"
"报告-究极进化版"
...
每个版本有各自的内容，但最终会只有一份报告需要被我们使用 。但在此之前的工作都需要这些不同版本的报告，于是每次都是复制粘贴副本，产出的文件就越来越多，文件多不是问题，问题是：随着版本数量的不断增多，你还记得这些版本各自都是修改了什么吗？
文档如此，我们写的项目代码，也是存在这个问题的！！
如何解决--版本控制器
为了能够更方便我们管理这些不同版本的文件，便有了版本控制器。所谓的版本控制器，就是能让你了解到一个文件的历史，以及它的发展过程的系统。通俗的讲就是一个可以记录工程的每一次改动和版本迭代的一个管理系统，同时也方便多人协同作业。 目前最主流的版本控制器就是 Git 。Git 可以控制电脑上所有格式的文件，例如 doc、excel、dwg、dgn、rvt等等。对于我们开发人员来说，Git 最重要的就是可以帮助我们管理软件开发项目中的源代码文件！
注意事项
还需要再明确一点，所有的版本控制系统，Git 也不例外，其实只能跟踪文本文件的改动，比如 TXT 文件，网页，所有的程序代码等等。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词"Linux"，在第8行删了一个单词 "Windows"。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
git的安装和卸载
git本地仓库的创建
创建一个文件夹，进入到文件内部，初始化文件
当成功的创建好本地仓库之后，首先要做的事就是为本底仓库配置两个配置项，这两个配置是必须要配置的（不进行配置的话，在以后进行向本地进行提交的话会报错），使用的命令是git config，配置好后通过git config -l选项就能够查看所有配置好的选项了
如果想删掉已经配置好的配置项，可以使用git config --unset
我们一台服务器上不止可以创建一个本地仓库，可以创建多个本地仓库，其中 --global 是一个可选项。如果使用了该选项，表示这台机器上所有的 Git 仓库都会使用这个配置。如果你希望在不同仓库中使用不同的 name 或 e-mail ，可以不要 --global 选项，但要注意的是，执行命令时必须要在仓库里
删除掉使用--global选项增加的配置项，删除时同样的需要加上--global
进入到gitcode文件内部，创建一个ReadMe文件
目前情况，Git能否管理ReadMe文件呢？不行的
文件已经放入到本地仓库中了，为什么不能够进行管理呢？
因为真正的本地仓库不是gitcode文件，而是隐藏文件.git，.git称为仓库，还称为版本库，有人就想了，在.git创建文件Git就可以对文件就可进行管理，这样也不行，并且也不能这样做，对于.git文件是不能进行任何手动修改的，如果误改、误删有可能造成整个本地仓库不能使用了。所以只能把ReadMe文件放在gitcode目录下，所以也称gitcode目录下为工作区，虽然.git也在gitcode目录下，但.git不属于工作区，是版本库
要想让Git进行对文件的管理，需要进行一系列的操作
stage称为暂存区，也称为索引（index），add会将工作区中的修改（修改包括新增、删除、修改）的内容添加到暂存区中（在版本库中还有一个object库（对象库），修改的工作区内容会写入对象库的一个新的git对象中，add会做的事：将工作区中修改的内容写入到对象库中，然后暂存区中的指针指向修改的对象），将内容添加到暂存区中，还不算将内容添加到版本库中，只有commit操作之后才算将文件提交到仓库中（commit做的事：让master中的指针指向对象库中的修改的对象）
-m选项是必加的，-m后跟的是本次提交的相关细节，这个细节一定要好好的描述，在版本管理的时候我们就能够看到这一版本的细节到底是什么
提交之后显示出本次提交中的版本和上一个版本有哪些变化，例如这里提示：新增了两行内容
再来介绍一个命令git log，能够帮我们打印出该本地仓库，所有由近期到过去的commit的操作
打印的内容：
commit后面跟的是commit ID，commit ID是由object下的文件名+文件中的对象名组成的
commit时所写的细节
也能够简单的显示
其实HEAD中所保存的是master文件的路径，而master保存的是最近一次commit的commit ID
commit ID是有一定的含义的，前面的f7是object对象库中的文件名，后面的是f7中所保存的对象名
查看commit ID
发现还可以显示出这次commit的上一次commit ID
此时，仓库中的 ReadMe 和我们工作区的 ReadMe 是不同的，如何查看当前仓库的状态呢？
git status：查看仓库的状态
显示内容：没有需要commit的、需要将内容add到暂存区，然后commit到仓库、修改文件：ReadMe
上面的结果告诉我们，ReadMe 被修改过了，但还没有完成添加与提交。目前，我们只知道文件被修改了，如果能知道具体哪些地方被修改了？
git diff [file] 命令用来显示暂存区和工作区文件的差异，显示的格式正是Unix通用的diff格式。也可以使用 git diff HEAD -- [file] 命令来查看版本库和工作区文件的区别。
-号表示改动前，+表示改动后
--- a/ReadMe表示改动前文件名叫ReadMe
+++ b/ReadMe表示改动后文件名叫ReadMe
-1, 2中的2表示下面中的内容的2行是改动前的文件的1、2行
+1, 2中的2表示下面中的内容的2行是改动后的文件的1、2行
add之后再次查看仓库的状态
版本回退
如果有一天你发现之前前的工作做的出现了很大的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退功能
执行 git reset 命令用于回退版本，可以指定退回某一次提交的版本，还可以回退到当前版本。要解释一下"回退"本质是要将版本库中的内容进行回退，工作区或暂存区是否回退由命令参数决定：
git reset 命令语法格式为： git reset [--soft | --mixed | --hard] [HEAD]
- --mixed 为默认选项，使用时可以不用带该参数。该参数将暂存区的内容退回为指定提交版本内容，工作区文件保持不变。
- --soft 参数对于工作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
- --hard 参数将暂存区与工作区都退回到指定版本。切记工作区有未提交的代码时不要用这个命令，因为工作区会回滚，你没有提交的代码就再也找不回了，所以使用该参数前一定要慎重。
HEAD 说明： - 可直接写成 commit id，表示指定退回的版本
- HEAD 表示当前版本
- HEAD^ 上一个版本
- HEAD^^ 上上一个版本
- 以此类推...
可以使用 ～数字表示： - HEAD~0 表示当前版本
- HEAD~1 上一个版本
- HEAD^2 上上一个版本
- 以此类推...
进行了版本回退，但是此时后悔了，也是可以返回到之前的版本
这里还有一个小点，就是如果把屏幕清掉，或者服务器关掉，就看不到前面版本的commit ID，此时如何回到前面的版本，使用git reflog，该命令能够查看每一次的版本记录，有了这个命令我们就能够知道具体要跳转到哪一版本
撤销修改
如果我们在我们的⼯作区写了很⻓时间代码，越写越写不下去，觉得自己写的实在是垃圾，想恢复到上⼀个版本。
情况一：
上面的情况是只对ReabMe添加了一行代码，类似这种情况直接将新添加的删除，但是也有可能我们开发了很多天了，一直都没有提交，该怎么删掉呢？你自己都忘了自己新增过哪些，有人想到，可以git diff xxx 一下，看看差别在删，那肯定又要花3天时间删代码了，并且很大的概率还会改出bug。
Git 其实还为我们提供了更好的方式，我们可以使用 git checkout -- [file] 命令让工作区的文件回到最近一次 add 或 commit 时的状态。 要注意git checkout -- [file] 命令中的-- 很重要，切记不要省略，一旦省略，该命令就变为其他意思了。
情况二：
情况三：
删除文件
在 Git 中，删除也是一个修改操作，如果要删除file3 文件，怎么做呢？
这里只是删除了工作区中file3，走到这里一般分为两种情况，一种是误删，另一种确实要删除，
对于第一种误删，由于删除也是修改操作，进行撤销就能够恢复
确实要删除一个文件
方法一：先使用rm -rf 删除工作区中的文件，然后使用add、commit提交到版本库中，删除版本库中的文件
方法二：使用git中的命令git rm，其做的步骤就是rm -rf 和add的步骤，接着commit
分支管理
分支是 Git 的强大功能之一，它允许你在同一个仓库中同时进行独立的开发工作线。你可以把分支想象成代码历史时间线上的一个独立分支点，在这个点上你可以进行修改、实验或开发新功能，而不会影响主开发线（master 分支）。
查看当前本地仓库有哪些分支
创建分支
每创建一个分支，refs/heads目录下就会多出一个分支，查看新分支和master分支，发现新创建的分支也是指向最新一次提交
切换分支，让dev_01成为工作线，需要让HEAD指向dev_01
我们可以看到无论是在工作区还是在版本库中dev_01分支与其他分支互不影响，在dev_01分支下对工作区中ReadMe文件做修改，然后add、commit，切到master分支下会发现其工作区中的ReadMe文件内容并没有修改。
合并分支
想让dev_01分支合并到master分支上，必须先切换到master分支上，在进行合并操作
合并成功后提示信息 - ReadMe文件增加了一行
- 1个文件发生了改变，新增了一行
合并后查看ReadMe文件中的内容发现已经更改
Fast-forward 代表"快进模式"，也就是直接把master指向dev的当前提交，所以合并速度非常快，当然，也不是每次合并都能 Fast-forward，我们后面会讲其他方式的合并。
删除分支
合并完成后, dev 分支对于我们来说就没用了， 那么dev分支就可以被删除掉，只能在其他分支中进行删除操作
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
合并冲突
在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
发生冲突git并不知道到底保留哪一部分内容，需要我们手动选择，并再次提交（手动解决冲突后一定要再次进行提交）
dev_01和master指向的一个变化
查看验证一下此时dev_01和master是否是如上图所示
用带参数的 git log也可以看到分支的合并情况，具体使用自行搜索git log 的用法:
