文章目录
1、Git简介
1.1 Git的历史
1.2 Git官网和Logo
官网地址：https://git-scm.com/
1.3 Git的优势
大部分操作在本地完成，不需要联网；
完整性保证；
尽可能添加数据而不是删除或修改数据；
分支操作非常快捷流畅；
与 Linux 命令全面兼容。
1.4 Git安装
从官网下载符合自己计算机操作系统的版本，安装在非中文没有空格的目录下即可。
1.5 Git结构
1.6 Git和代码托管种行
代码托管中心的任务：维护远程库。
局域网环境下：
GitLab 服务器
外网环境下：
GitHub
码云
1.7 本地库和远程库
1.7.1 团队内部协作
1.7.2 跨团队协作
2、Git基本操作
2.1 本地库初始化
命令：git init
作用：在文件夹创建一个.git文件夹表示该文件夹已被Git管理。
注意：.git 目录中存放的是本地库相关的子目录和文件，不要删除，也不要胡乱修改。
2.2 设置签名
签名是Git验证提交者身份的一种机制，这里设置的签名和登录远程库(代码托管中心)的账号、密码没有任何关系。
为什么叫签名而不叫用户名呢？是因为在早期，一个员工完成一项任务，都需要在纸质文件上签名证明是他做的，Git的签名就来源于此。
签名分两种级别：项目级别和系统用户级别。
例如：小A程序的name为XiaoA，邮箱为[email protected]。
命令：
项目级别用户名：git config user.name XiaoA
项目级别邮箱：git config user.email [email protected]
系统级别用户名：git config --global user.name XiaoA
系统级别邮箱：git config --global user.email [email protected]
项目级别的签名保存在仓库的.git\config文件里，系统级别的签名保存在~/.gitconfig文件里。
级别优先级：就近原则，项目级别优先于系统级别。至少有其中一个。
2.3 查看状态
命令：git status
作用：查看工作区、暂存区的状态。
2.4 添加
命令：git add [file name]
作用：将工作区的“新建/修改”添加到暂存区（注意：add不是添加文件，而是添加操作）
2.5 提交
命令：git commit -m "提交注释内容" [fine name]
̳作用：将暂存区的内容提交到本地库。
2.6 查看历史记录
命令1：git log
作用：显示本地库的所有详细的历史信息。
命令2：git log --pretty=oneline
作用：每条历史记录用一行显示。
命令3：git log --oneline
作用：更简洁显示历史记录，hash值只显示前几位。
命令4：git reflog
作用：显示HEAD的移动轨迹，所以显示重复的版本，说明HEAD来回走过。
2.7 版本前进后退
2.7.1 基本操作
版本的前进后退本质是移动HEAD指针指向指定的版本。
命令1：git reset --hard [局部索引值]
作用：切换到指定版本
命令2：git reset --hard HEAD^
作用：一个^表示根据当前HEAD后退一个版本，n个表示后退n个版本
命令3：git reset --hard HEAD~n
作用：根据当前HEAD后退n个版本
建议使用命令1，比较直观。
2.7.2 reset命令的三个参数对比
--soft：仅仅在本地库移动HEAD指针；
--mixed：在本地库移动HEAD指针+重置暂存区；
--hard：在本地库移动HEAD指针+重置暂存区+重置工作区。
2.8 删除文件并找回
大前提：文件已经提交到了本地库。
操作：git reset --hard [指针位置]
其实原理就是回退版本，找到未删除前的版本。只要没有清空本地库，数据永远在本地库，无论你怎么改，都会生成新的版本，旧版本依旧不变。
2.9 比较文件的差异
命令1：git diff [文件名]
作用：将工作区中的文件和暂存区进行比较。
命令2：git diff [本地库中历史版本][文件名]
作用：将工作区中的文件和本地库历史记录比较。
不带文件名则比较全部文件。
3、Git基本原理
3.1 哈希
哈希是一个系列的加密算法，各个不同的哈希算法虽然加密强度不同，但是有以下几个共同点：
1、不管输入数据的数据量有多大，输入同一个哈希算法，得到的加密结果长度固定；
2、哈希算法确定，输入数据确定，输出数据能够保证不变；
3、哈希算法确定，输入数据有变化，输出数据一定有变化，而且通常变化很大；
4、哈希算法不可逆。
Git 底层采用的是 SHA-1 算法。哈希算法可以被用来验证文件。原理如下图所示：
3.2 Git保存版本的原理
3.2.1 集中式版本控制工具的文件管理机制
集中式版本控制工具的文件管理机制以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。
3.2.2 Git的文件管理机制
Git 把数据看作是小型文件系统的一组快照。每次提交更新时 Git 都会对当前的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。所以 Git 的工作方式可以称之为快照流。
在进行提交操作时，Git 会保存一个提交对象（commit object）。 该提交对象会包含一个指向暂存内容快照的指针，还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。 首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象， 而由多个分支合并产生的提交对象有多个父对象。
当使用 git commit 进行提交操作时，Git 会先计算每一个子目录的校验和， 然后在 Git 仓库中这些校验和保存为树对象。随后，Git 便会创建一个提交对象， 它除了包含上面提到的那些信息外，还包含指向这个树对象（项目根目录）的指针。 如此一来，Git 就可以在需要的时候重现此次保存的快照。
假设现在我有一个工程项目，里面包含三个文件：README、test.rb和LICENSE，首次commit后：
先给项目中每个文件创建一个blob对象（保存着文件快照），然后创建一个tree对象（记录目录结构和blob对象索引），最后创建一个commit对象（包含着指向tree对象的指针和所有提交信息，如作者、邮箱等）。到此，一个完整的本地库版本快照保存好了。
当修改了项目，进行第二次commit后，产生的提交对象会包含一个指向上次提交对象（父对象）的指针。
4、Git分支管理
4.1 什么是分支
Git 的分支，其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master。 在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支。 master 分支会在每次提交时自动向前（新版本）移动。
分支的好处：
1、同时并行推进多个功能开发，提高开发效率。
2、各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。
4.2 Git分支管理机制
4.2.1 创建分支
命令：git branch [分支名]
例如：git branch testing
作用：创建一个testing指针，初始时指向建立分支所在的分支。
创建后可通过git branch -v命令查看存在的所有分支。
4.2.2 切换分支
命令：git checkout [分支名]
例如：git checkout testing
作用：HEAD指针指向testing分支，此时工作区和暂存区也更新为testing分支的信息。
分支进行修改并提交：
4.2.3 合并分支：
第一步：切换到接受修改的分支：git checkout [接受合并的分支]
第二步：执行命令git merge [有新内容的分支]
合并后，HEAD指向新版本：
4.3 分支冲突
4.3.1 冲突的表现
4.3.2 解决冲突
执行merge命令，当存在冲突时，会进入一个临时分支，在这个分支上解决冲突。
第一步：编辑冲突文件，删除特殊符号；
第二步：把文件修改到自己满意程度，保存退出；
第三步：执行git add [修改好的文件]和git commit -m "提交注释"
执行完三步后就会退出这个临时分支，进入到合并后的全新版本。