引子
上周公司同学因为操作不慎丢失了部分代码，费了好大得劲才找回来。究其原因，是几位开发同学联合在一个分支上开发，对rebase操作不太熟，有人rebase操作后，其他同学pull之后丢失了部分自己的代码。好在未造成严重后果，不然可能又是一个提桶跑路的故事。
rebase的作用
虽然已经使用git好几年了，但是一般开发过程中主要是使用checkout、pull、status、add、commit、push、stash、stash pop、merge这些比较常用命令，对rebase的使用非常少，刚好借这个机会再学习一下rebase的作用和适用场景。
合并提交
我们在本地开发过程中，可能会有多次commit记录，push上去的话，git log一眼看去全是你一个人的提交，对其他也在这个工程开发同学很不友好。
这个时候，我们可以使用rebase来合并几次本地的commit，这样在git log中体现出来就会干净很多
我们在idea中实际操作一下
创建3次提交，分别是commit7、commit8、commit9，使用git log查看记录
执行git rebase -i HEAD~3，合并最近的3次commit
执行后，首先会出现一个rebase的操作配置文件
最上面是3个待合并的commit记录，下面是对这些分支怎么处理的配置说明：
rebase对分支的操作配置
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
# commit's log message, unless -C is used, in which case
# keep only this commit's message; -c is same as -C but
# opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]一般我们要合并几次commit的话，可以把最上面的1次commit配置为pick(可以简写为p)，把其他的commit配置为squash(可以简写为s)，如图所示：
通过:wq保存后，接下来会进入确认commit message的文件：
如果还是沿用原始的commit message，那么就不需要做任何更改，如果合并后需要对commit message做精简或者扩展，就可以直接修改这个文件，跟上面的文件一样也是vi操作，保存后，会有rebase成功的提示：
再次通过git log查看，可以看到3次commit已经被合并成1次：
为了方便阅读，我把前面未合并的git log截图再贴出来一次做对比：
可以看到，rebase合并几次请求，让git log更干净。
合并分支
一般而言，我们合并分支都是使用git merge命令。例如开发同学A、B都在projectX进行开发，各自基于master拉取了各自的开发分支featureA和featureB。同学A的开发任务相对简单，这个分支在featureB在开发的过程中就发布了，合并到了master分支。
这时候分支B就落后于最新的master，这时候我们一般使用merge master来合并这部分修改，让featureB是最新的分支。
rebase合并分支的作用是指，分支A使用rebase来合并master，执行git命令git rebase master，featureB就像基于新的master拉出来一样
危险
我们说rebase是一个危险的操作，其实就在于上面一步git rebase master。试想一下，如果featureB还有一位开发同学C，本来他有1次commit，但是开发同学B执行rebase后，featureB的来源变成了新的master，而开发同学C的更改就丢失了。
总结
rebase的主要作用有2个：
- 合并多次commit
- rebase master减少merge master操作
第2个操作是个危险操作，如果有多位开发同学的情况下，不当操作可能会导致代码丢失。
题外话
对于git rebase master，执行后，让featureB就像基于新的master分支一样，这个作用让rebase有了另外一个名字--变基。
虽然这个名字让人会产生其他的联想，但是非常精准的解释了这个操作的作用，而强制更变了来源，导致git在判断新旧版本的时候，跟人下意识的理解产生了不一致，这里是危险的来源。
看到这里了，点个赞再走呗
