1. git基本操作
1.1git简介
产生历史
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两大特点
版本控制：可以解决多人同时开发的代码问题，也可以解决找回历史打码的问题。
分布式：Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。首先找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器中拉取别人的提交，可以自己搭建这台服务器，也可以使用Github网站。
1.2 git 版本库创建
首先创建一个工作的目录 git_test
在git_test目录下创建一个版本库，命令如下
1.3 版本创建与回退
创建一个文件并进行编辑
使其保存成一个版本（两行命令）
查看版本记录 git log commit 为版本序列号 -m 参数指定说明信息
使用简短的方式显示 git log --pretty=oneline
继续修改code.txt
保存版本
如图，版本二依赖于版本一，版本二只是记录与版本一不同的内容
版本回退，存在一个HEAD指针
HEAD^ 倒退一个版本 HEAD^^ 倒退两个版本 以此类推 HEAD~10 倒退前10个版本
此时如果需要回到版本二 使用命令 git reset --hard 版本序列号（commit）
如果关闭终端后无法找到版本编号，可以重新打开终端使用命令 git reflog 查看以前操作的记录
1.4 工作区和暂存区
工作区：电脑的目录，比如上面的 git_test，就是一个工作区。
版本库：工作区有一个隐藏目录 .git ，这个不是工作区，而是版本库。
git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有git为我们自动创建的第一个分支master，以及指向maser的一个指针叫HEAD。
当创建 git 版本库时，git 自动为我们创建了唯一一个master分支，所以，现在，git commit 就是往master分支上提交更改。
可以简单理解为，需要提交的文件修改统统放到暂存区，然后，一次性提交暂存区的所有修改。
把文件往git版本库里添加的时候，分两步执行：
第一步 git add 把文件添加进去，实际上就是把文件修改添加到暂存区。
第二步 git commit 提交修改，实际上就是把暂存区的所有内容提交到当前分支（创建版本记录）。
使用 git status 查看当前的工作状态
code.txt被修改， code2.txt 是未跟踪的文件（新创建的文件，在未git add之前，git就会提示是未跟踪的文件）
提交到暂存区，status显示 要提交的变更
使用git commit 一次性提交暂存区的所有修改，如图
提交后，如果你又没有对工作区做任何修改，那么工作区就是“”干净”的。
此时使用git status 查看状态 没有修改无文件提交，干净的工作区
1.5 git 管理修改
git管理的文件的修改，它只会提交暂存区的修改来创建版本
编辑code.txt 增加一行，查看状态，提交到暂存区，查看状态
继续编辑code.txt 增加一行，git status 提示有未暂存以备提交的变更
直接git commit ，再git status ，第一次的修改已被创建为新版本 如图
1.6 git 撤销修改
如上图提示，使用 git checkout 丢弃工作区的改动
如图，使用命令git reset HEAD <file> 撤销暂存区的修改，重新放回工作区，此时可以如上图操作
小结：
1.6 对比文件的不同
对比 工作区 和 某个版本中 文件的不同
编辑code.txt
使用 git diff HEAD -- <文件名> 进行对比
前面没有出现 + - 的是都有的内容
- 对应 HEAD版本的code.txt + 代表工作区里面对应的code.txt
工作区 code.txt 比HEAD版本的 code.txt 多了一行
对比 两个版本之间 某个文件的不同
比较 HEAD版本 和HEAD^ 版本的 code.txt 的不同，使用如下命令
前面没有出现 + - 的是都有的内容
- 对应 HEAD版本的code.txt + 代表HEAD上一个版本的 code.txt
此时 - 代表HEAD上一个版本的 code.txt + 对应 HEAD版本的code.txt
即第一个参数为准，第二个参数，则相对于第一个参数进行对比（第一个不是HEAD时，不写，默认和HEAD版本比较）
1.7 git 删除文件
丢弃工作区删除 code2.txt 改动
在工作区删除文件提交到暂存区（删除可以使用 git rm）
同理使用 git reset HEAD <file> 可撤销暂存区的修改，重新放回工作区
提交到版本库
小结
补充：
当创建一个新文件并没有提交到过缓存区时，文件没有被跟踪，此时删除文件，不能使用git恢复
综上，一图汇总
2. git分支管理
2.1 git 分支基本操作
廖雪峰：https://www.liaoxuefeng.com/wiki/896043488029600/900003767775424
查看当前有几个分支，并且看到在哪个分支下工作：git branch
创建新的分支，并切换到其上进行工作 git checkout -b 分支（ 操作分支很快，只是改变指针的指向或生成删除）
------- >>> 
编辑code.txt
切换回master分支（指针改变指向即可）
合并dev分支 git merge （快速合并）
合并完删除dev分支 git brach -d 分支 （移除指针）
小结
待补充，恢复删除的分支
2.2 git 分支_解决冲突
创建一个新分支 dev ，并切换到dev分支，编辑 code.txt，进行提交
切换到master分支，编辑code.txt 进行提交
此时将 dev分支 合并到 master 分支上，报错 code.txt 文件存在冲突，自动合并失败，必须手动解决冲突后再提交
此时打开我们的冲突文件 code.txt，如图，冲突内容很明显，我们进行编辑
---------->>>> 
此时我们在master分支，进行提交
使用 git log --graph 查看效果图
完成后即可删除 dev 分支
2.3 git 分支_分支管理策略
通常，合并分支时，如果可能，git 会用 fast forward 模式，但是有些快速合并不能成功，并且合并时没有冲突，此时，
git 会帮助你合并，并做一次重新提交，但这种模式下，删除分支后，会丢失分支信息。
eg： 创建并切换到 dev 分支，新建一个code.txt3 编辑并提交，切换回master分支，编辑 code.txt 并进行提交
此时如果合并dev分支到master主分支上就是上述效果，此时合并并不会有冲突（dev分支新建文件code3.txt进行编辑，而master分支编辑code.txt），但是此时合并，并不能快速合并，即简单的更换指针的指向，如下图所示
进行合并 git merge dev，如图，此时是 git 帮你提交，此时需要在此页面编辑你的说明信息
删除分支dev
如果强制禁用 fast forward 模式，git 就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息
eg：创建并切换到 dev 分支，修改code.txt内容，并提交，切换回master分支
此时，使用git merge dev 会使用快速合并，不会有冲突，dev分支有提交几率，master分支未修改，直接移动指针即可
但是，我们为了保存提交分支的记录，需要手动禁止快速合并
使用 git merge --no-ff (no fast forward) 禁止快速合并，此时git 帮你提交，需要有一个说明信息
删除 dev 分支
2.4 git 分支_bug分支
开发时，有了bug就需要修复，在git 中，由于分支的强大，所以，每一个bug 都可以通过一个新的临时分支来修复，修复后，
合并分支，然后将临时分支删除。
场景：
当需要修复一个代号 001 的bug 的任务时，很自然地，需要创建一个分支bug-001 来修复它，但是此时在dev的工作还没有提交
并不是你不想提交，而是工作进行到一半，无法提交，完成需要一个，而必须在短时间解决bug
git 提供一个 stash 功能，可以把当前的工作“存藏”起来，等以后恢复现场后继续工作
我们创建并切换到 dev 分支，编辑修改code.txt内容（工作ing）
为了修复bug，并不影响当前工作，此时就可以使用 git stash 把当前的工作“存藏”起来
此时假定 master分支上的 code.txt存在bug，我们需要切换到master分支上再创建一个临时分支来修复bug，进行修复，提交
在临时分支进行修复，提交
修复完成后，切换到master分支，提交，并完成合并，最后删除bug-001临时分支
注意：此时为了保存分支记录，不能使用快速合并
回到dev分支 继续 工作，使用 git stash list 列出“存藏”的工作现场， git stash pop 恢复工作现场
如图，回到了编辑code3.txt的状态
小结
综上，一图汇总
3. Github使用
3.1 创建仓库
自定义 .gitignore
3.2 github_添加SSH公钥（免密登录）
点击头像
使用 ssh-keygen -t rsa -C ‘邮箱地址’ 生成SSH秘钥
三个回车
复制选中内容，提交
3.3 github_克隆项目
找到你要克隆的项目界面，这里选择的是SSH协议克隆（我们添加的就是ssh公钥）
命令行克隆
两次提交，第一次是创建仓库时的提交，第二次是编辑.gitignore文件的提交
克隆出错，可尝试下图命令解决
3.4 github_推送代码（上传分支）
创建自己的分支进行开发
本地提交
此时，将自己完成的分支推送到github远程的分支上（github上没有此分支，会创建该分支）
使用命令 git push orgin 分支名称
3.5 将本地分支跟踪服务器分支
跟踪后，本地提交和远程提交不一致会提示你
使用命令 git branch --set-upstream-to=origin/远程分支名 本地分支名
此时编辑文本，本地提交，查看状态
提示我们本地分支领先远程分支一个提交
我们推送到远程分支上
此时我们本地分支跟踪了服务器分支，可直接push 不需要写后边的内容
解除远程关联
3.6 github_拉取远程分支代码
git pull orgin 分支名称
这里报错，某种情况就是线上环境代码与本地代码不一致，保留线上环境，不应用本地改动
git使用流程
