每天对自己多问几个为什么，总是有着想象不到的收获。 一个菜鸟小白的成长之路（copyer）
rebase：变基
目的： 就是让git的提交记录变得更加的简洁。
使用场景1：简化提交记录
举例： 组长给你安排了一个大的功能模块（比如说购物车功能），让你自己独立的开发，给你五天的时间。那么你就会从dev分支上，在单独拉去一个分支，开发购物车功能，你每天都会使用git commit来记录你每天的工作量，五天就会产生五个commit，当你交给你组长的时候，这五个commit对你组长来说，是没有用的，他只需要你的最后一次代码提交，所以，你就可以把无用的commit进行合并。
简单举例：
// 这里就把master想象成开发分支， dev想象开发的购物车的分支
git init
touch master.js
git add .
git commit -m 'master分支上的最初版本'
// 拉取一个开发购物车分支
git checkout -b dev
// 接下来就进行开发
// 第一天
touch dev1.js
git add .
git commit -m '购物车静态页面的实现'
// 第二天
touch dev2.js
git add .
git commit -m '购物车的逻辑实现1'
// 第三天
touch dev3.js
git add .
git commit -m '购物车逻辑实现2'
// 第四天
touch dev4.js
git add .
git commit -m '接口联调'
// 第五条
touch dev5.js
git add .
git commit -m '购物车功能的优化'
//然后这时候，就可以把代码合并到master分支上了
如果合并，其中很多的commit信息是没有用的，所以需要合并。
git rebase的基本用法
git rebase -i [startpoint] [endpoint]
其中-i的意思是--interactive，即弹出交互式的界面让用户编辑完成合并操作，[startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支HEAD所指向的commit(注：该区间指定的是一个前开后闭的区间)。
这里的commit hash值一般截取前面的几位字母就行了
git rebase -i 9c9d69bc
或者：
git rebase -i HEAD~5 // 向前合并几个，这里需要自己去数
这里，自己就有点失算了，哈哈哈。这里是**前开后闭**的，所以选择9c9d69bc，合并的时候，是不会包括购物车的静态页面的实现 。这里发现问题了，以后就要多注意了，希望以后不会在犯了。
上面的截图中，有一个指令区域：
pick：保留该commit（缩写:p）
reword：保留该commit，但我需要修改该commit的注释（缩写:r）
edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
squash：将该commit和前一个commit合并（缩写:s）
fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）
exec：执行shell命令（缩写:x）
drop：我要丢弃该commit（缩写:d）
这里主要就是使用 s，将该commit和前一个commit合并（缩写:s）。
修改后的截图：
上面 截图选中的部门，就是默认的提交信息，这里，我们就可以改改这个提交记录，改成购物车功能的实现完成。
git log
上面 1 就是前面四条的合并的总的记录。
注意事项：
上面的
2这个commit 的提交已经被push到远程仓库中，就最好不要合并，不然就会引出不必要的麻烦出来
使用场景2： 简化分支的主树干
在上面的笔记中，学习了merge这个命令，这里合并，就会是主树干 变的很复杂
https://blog.csdn.net/James_xyf/article/details/120809220?spm=1001.2014.3001.5501
这里有一个分支，就有一个分叉，那么如果分支多了，就是分支变得复杂，跟蜘蛛网一样的。
那么rebase就可以简化树干。
过程图，还是这样的。
图画的有点丑，但是大致意思应该都明白。
流程开始了。
1、先创建一个git管理的文件夹
git init
2、创建master1.txt，然后add commit
touch master1.txt // 创建一个文件夹
git add .
git commit -m 'master c1'
3、创建master2.txt，然后add commit
touch master1.txt // 创建一个文件夹
git add .
git commit -m 'master c2'
4、在master c2的基础上创建一个分支dev，然后创建文件 dev1.txt add commit
git branch dev
git checkout dev
// 等价于
git checkout -b dev
touch dev1.txt
git add .
git commit -m 'dev c1'
5、切换回master分支，继续创建master3.txt，然后 add commit
git checkout master
touch master3.txt
git add .
git commit -m 'master c3'
6、切换到dev，在dev分支上rebase ，合并master分支
git checkout dev
git rebase master
7、然后切换到master分支，merge 合并dev分支
git checkout master
git merge dev
git log --graph --pretty=format:"%h $s"
这样树干，就是直接一条线了。
跟merge的区别：
merge合并的时候，会产生一条新的commit记录
rebase则不会产生新的commit
git rebase产生冲突
在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:
$ git rebase --continue
这样git会继续应用(apply)余下的补丁。
在任何时候，你可以用--abort参数来终止rebase的行动，并且"dev" 分支会回到rebase开始前的状态。
$ git rebase --abort
总结
git rebase的目的就是用来优化
// 合并commit提交记录
git rebase -i [startpoint] [endpoint]
// 合并分支
git rebase master