我们在工作中，可能会出现这样的情况，一项工作由好几个同事同时完成，然后每个人针对当前的feature都有对应的提交，那么就会造成同一个feature有多次提交的这样的冗余存在；除此之外，如果我们自己针对同一个feature的每天的提交以及一些细微的修改（代码格式或者一些typo），这样的commit是没有必要全部push到远程服务端的，那么这个时候我们就需要用git rebase 这个工具来“压缩”一下这些commit信息，换一句话说，就是把这些提交信息汇总成一条然后push给远程服务器。
我们在本地来做这么个实验，在工作区，我们发起三次commit。
现在我们发起第四次提交，然后我们发现，第四次提交与第三次和第二次都属于同一个feature（假设），然后我们想第二个，第三个，第四个commit汇总为一个commit，然后合同第一个commit一同push到服务器去。
那么现在就是rebase上场的时候了。
git rebase -i [start] [end]
上式表示，从start的commit开始（不包含start的commit）到end结束，这之间的所有commit汇聚成一条commit
-i 参数表示 interactive，即与用户进行交互
那现在我们就可以使用
git rebase -i 1053ed 0ec702
其中1053ed 是first commit的哈希值，0ec702是forth commit的哈希值。这条指令一执行，就会出现以下的画面（这里我机子上vim默认用VSCode打开）
上面的文档是一个vim界面的文档（与之前commit提交信息的相似），文档的上半部分代表这次rebase会提交的信息，会发现，这里每条信息都是由三部分组成
Command + Commit Hash + Commit comment
其中command代表命令，下面注释部分有多种命令的说明，默认的pick代表当前的当前commit会被出现在rebase后的提交信息中。我们这里希望仅仅只保留一条commit（即三合一），所以我们把forth commit和third commit的pick均改外squash，即合并到上一条commit中，改好保存，关闭编辑器，git 则会弹出下一个窗口
这个窗口就是commit信息窗口啦，现在second，third，forth三个commit已经合并成了一个commit，但是新的这个commit是需要commit信息的，所以这里就是写commit信息的地方（同样，此处的注释掉的部分是不会显示到最终的提交信息中的），这里我们仅把第一行的注释符号去掉，不修改其他任何信息，然后提交。然后提示rebase成功
Successfully rebased
然后我们再看 git log信息
之前的second commit， third commit，forth commit不见了，取而代之的是一个新的commit信息，而且新的commit hash值也发生了改变，说明这是一个完全全新的提交。
假如我们现在有这么个情况发生。
主线上有MAS commit 1和MAS commit 2两次提交，然后在MAS Commit 2的时候，我们拉出了一条dev分支用于开发一个功能，然后直到这个功能开发完成共计向本地仓库提交了三次，到了DEV commit 5处，当准备向master主线提交merge之前，主线master被更新了，先于dev分支，走到了MAS commit 6处（此时，DEV commit 5还是基于 MAS commit 2的修改）。
此时，我们想把DEV commit 5与主分支进行合并，我们可以有两种做法，一种是采用merge的方法，把当前分支与master分支直接进行merge，然后解决冲突后push到服务器，这时，会形成一个新的commit节点，如下图的MAS commit 7，而且在working tree上也是按照提交的时间先后顺序进行排列的。
上面的例子是用merge的方式做，另一种方法是用rebase来做，rebase的话，会把DEV commit 3，4，5 均基于MAS commit 6做修改而形成：
这里，主线和分支的提交均按照线性时间进行排列了，而且DEV分支已经基于最新的master提交进行了rebase，所以换句话说，rebase后的commit 3，4，5应该说已经不再是以前的commit 3，4，5了，而且它们的commit hash值已经发生了变化。
此时，再执行git merge 即可。
总结下，上述情况发生时的两种处理方式