rebase，直接翻译这个单词的意思是从新以…为基础的意思. 在git中rebase用来再次定义提交起点的位置. 何为起点的位，如下图，如果我继续提交代码一定是从C处开始的.
rebase就是从新去定义这个提交位置，例如我可以把Head指向A或者B.
在我看来主要有3个作用
1，定期合并主干分支到开发分支，或者开发分支到feature分支
2，本地分支代码的版本已经落后远程分支代码版本，通过rebase可以不用去merge远程分支代码，从而减少多余的commit纪录，使得提交纪录整洁
3，合并commit纪录,合并commit纪录的好处是，当我们进行feature分支开发后合并到develop分支中，提交纪录更为整洁.
下面分别来说说这三种情况:
1，定期合并主干分支到开发分支，或者开发分支到feature分支
在开发过程中我们会遇到这样的情况，feature分支开发的同时，dev分支也有别的分支的merge生产的commit, 这个时候feature分支和dev分支的差异就会变大，过多的差异可能导致最终导致最终merge到dev分支过于复杂.
为了减少这种差异，所以需要定期去rebase dev分支上面的代码。当然最终merge到dev分支之前进行一次rebase我认为是必要的，因为通常负责把feature分支合并到dev分支的人都不是开发该feature分支的人，只有开发feature分支的人才最清楚如何解决代码合并带来的冲突.
上图展示了merge到dev分支之前feature分支执行rebase操作后再merge到dev分支中.
2，本地分支代码的版本已经落后远程分支代码版本，通过rebase可以不用去merge远程分支代码，从而减少多余的commit纪录，使得提交纪录整洁
$ git push origin master
To git@gitee.com:micaixiaoduanku/Demo.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'git@gitee.com:micaixiaoduanku/Demo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
这种情况通常会在push代码的时候遇到,在本地代码和远程代码版本不同步的情况下是不允许进行push.
当然你可以选择force push,但是这样会冲掉远程仓库的代码和提交记录，一般不会使用force push.
因为本地代码仓库对应的远程代码仓库不同步了，所以通常会让你先pull代码，进行merge操作后，再次提交. 但是这种操作会带来一个不好的地方，就是产生一个merge的commit, 因为push代码的时候遇到这种情况还是蛮多的，在开发过程中势必会产出过多的merge commit纪录，这样造成提交纪录冗余。如果使用rebase就可以很好的避免这个弊端.
如图所示产生的提交3是作为一个merge的commit,rebase通过重新定义提交起始位置可以忽略掉merge commit，如下图所示：
通过rebase，重新把提交起始位置放在了D处，D处提交之前需要做一个rebase操作，这个rebase操作包括（这个操作包括merge和解决冲突），并一并提交上去作为一个新的commit D. 这样做的好处显而易见，它并没有产生merge的commit, 而仅仅是一个push的 commit.
3，合并commit纪录,合并commit纪录的好处是，当我们进行feature分支开发后合并到develop分支中，提交纪录更为整洁.
常常在开发feature分支的过程中，我们总是不断的完善feature分支,也使得commit纪录会越来越多，当想合并到dev分支的时候，往往并不希望把feature分支的commit纪录合过去，这个时候我们可以使用rebase去把commit提交纪录合并成为一个.
这样作为一个commit再merge到主分支提交记录就会更为简洁.
