Git杀手锏特性-Git分支模型
分支在Git中是以一个索引字符串文件形式存在(分支所指向提交的长度为40个字符的SHA-1的校验和).
这使得Git创建分支和删除分支成本很低，也是和其他版本控制系统拉开差距的杀手锏特性之一。
Git分支的基本常用命令
创建test分支并切换到目标分支上
git checkout -b test
查看本地所有分支
git branch
分支切换
git checkout master
创建分支但不切换分支但head指针并不移动：
git branch test
查看各个分支当前所指向的对象
git log --oneline --decorate
查看当前分支是从哪个源分支切出：
git reflog --date=local --all|grep 你的分支名称
注意:上面这个命令是查看的是在本地分支切换日志，只有分支创建人执行此命令才能看到源分支是哪里的(按照时间顺序查看最早的那条日志)，否则只能看到自己本地涉及到此分支的切换日志。 注意，如果日志的最后一行是：
没有源头分支，说明checkout分支时，只是从head指针上切分支，并不清楚当前切的时候head指向是哪个分支，为保证不出意外，最好新切一个 正常应该显示这个
日志的最后一行代表的是分支的来源 分页查询如下：
git reflog --date=local --all | grep "关键字" | less
查看当前所有分支的最新提交
git branch -v
查看当前分支在历史上哪些分支并入
git branch --merged
查看哪些分支历史上没有并入
git branch --no-merged
冲突解决后查看状态
git branch status
- 可以看到test、origin/master,zq_test,master 分支都显示在16d5913提交旁边。
- 使用场景：查看当前分支的是从哪个分支切换来的，上图所示，test分支是从 zq_maindada分支切换而来。
删除分支（当前head指针指向dev分支时不能删除dev分支）
git branch -d dev
强制删除分支
git branch -D test
git 提交
git commit -a -m 'made other changes'
查看项目历史的分叉情况（和idea中的项目历史类似）
git log --oneline --decorate -- graph
分支合并
①切换回master分支，保证当前分支是要合并的目标分支
②执行命令
git merge hotfix
Fast-forward提示
如果master分支所指向的提交是 要并入hotfix的分支直接上游，那么git会直接将master分支的指针向前移动。
当你试图去合同两个不同的提交，而顺着一个提交的历史可以直接到达另一个提交时，git会简化合并操作，直接把分支指针向前移动，因为这种单线历史不存在有分歧的工作。(个人理解：这也可以一定程度判断当前分支是否和其他分支有冲突。）
git工作流使用场景
1、你需要进行一个优化的开发；
2、你在优化工作进行时临时需要一个紧急bug修复
那么假设
1、你从master分支上检出分支正在进行优化；
2、你又从master分支上检出分支做bug修复；
那么在bug修复完成后，你的优化分支上没有bug修复的代码，你可以有两种办法处理
① git merge master ，让master分支合并到优化分支中。
②在优化分支合并到master分支时把hotfix的工作整合进来。
基本的三方合并提交
A:共同祖先提交 B:当前开发的最新提交 C:目标分支的最新提交
以上为git最常用的简单的三方合并
同一个文件不同分支上的版本对比及合并
随后进行版本之间对比和手动合并
git stash
使用场景：如果你本来在功能分支上进行开发，但是线上忽然有bug,本地分支此时尚未开发完成，还不能提交，可以用git stash
drop stash 删除stash pop stash 应用后删除stash记录（比较常用） clear stash 删除全部stash --慎用 apply stash 应用当前stash
使用git stash需要注意的点，如果其他的分支工作完成后，再切回分支，首先需要先unstash,即恢复stash的工作内容，如果忘记恢复stash，还在老版本代码上进行更改，会提示首先将已经更改的内容进行commit，或者再次进行stash，然后按照stash的时间顺序先后恢复即可。(个人理解：这里和git无法将stash内容和已经更改的内容无法合并读取有关)
drop commit
直接删除此次提交，且在提交历史中也不存在，不可撤回
rever commit
将这次提交回滚后，且生成一个新的提交，但是历史提交还在历史提交线中
git cherry pick
应用场景：自己的代码被同事覆盖掉（PS:记住：只要代码进行commit了，一定有办法恢复！！）
此功能也叫代码遴选功能，比如 一些改变3被revert,此时需要恢复一些改变3，那么进行cherry pick后又会在提交线中刚生成条新的。
但是如果是多个提交进行cherry-pick 需要有时间顺序，比如此时 pick 1,2 那么3也需要手动判断是否合并到当前文件中
git 提交线
3 是在A分支的代码提交，2是B分支的代码提交，1提交是 2提交、3提交的共同祖先提交
将A分支合并到B分支后自动生成合并提交4
合并提交一定是至少有两个父提交，这里 2、3 都是4的父提交
那么在右侧会显示这次父提交有变更的内容，（两个分支上）
已经合并主分支撤回合并
如果直接revet合并提交会报错
需要标识哪些是主线分支 记住在撤回合并提交时，当前所在分支一定是主分支。
那么 提交[D子线的一些改变5]就会被取消合并了
如果需要对zq_git_test_child进行一些改变后再次合并到zq_git_test分支上 那么
如果此时再进行合并 会发现 [D子线的一些改变5]并没有合并到 zq_git_test分支上
对之前撤回提交进行revert
发现 [D子线的一些改变5] 又回来了。
遇到一个特别坑的事情，idea本地发现dev合并到了master生产分支上，有个待push的标志 但是本人也没有印象有误操作(也有可能是打电话的时候误操作了)
但是没有推送到远程，一切都好说！
重新拉一下仓库代码就行啦！
