git rebase
git pull -r
在push代码时，会提示使用git pull命令，也就是拉取远端代码，更新我们的仓库，那么为什么又要加个 --rebase命令呢？
git pull = git fetch + git merge FETCH_HEAD
git pull --rebase = git fetch + git rebase FETCH_HEAD
二者的区别是，在fetch之后的操作不同，merge与rebase的不同。
假设当前master的提交如下：
如果是你或者你的同事在cid2点，开发进度是cid20(或者突然撇出一个分支，假设是tmp分支），此时要把cid20提交到master
在master执行git merge tmp,然后会得到如下结果：
新增了一次提交记录cid6, 似乎也没有什么问题。如果查看提交日志，可能就是下面的样子：
那么来看看git rebase, 在master执行git rebase tmp，操作之后的分支如下：
二者对比可知，rebase没有产生新的节点，使用rebase的git演进路线(提交树)是一直向前的，这样在版本回退时也很容易，用merge的git路线是跳跃的，如果版本回退你也找不到自己想要的版本，如果在merge时出现了冲突那就麻烦了，当前merge就不能继续进行下去，需要手动修改冲突内容后，add，commit, push. 而rebase 操作的话，会中断rebase,同时会提示去解决冲突。解决冲突后, 再执行 git rebase –continue 继续操作，再push.
想要更好的提交树，建议使用rebase操作会更好一点，这样可以线性的看到每一次提交，并且没有增加提交节点。不过也有些项目，不建议使用rebase, 这就得看公司与项目的规定。
git rebase 合并分支
git checkout feature
git rebase master
等价于
git rebase master feature
推荐使用场景
其实是最重要的。不同公司，不同情况有不同使用场景，不过大部分情况推荐如下：
- 自己单机的时候，拉公共分支最新代码的时候使用rebase，也就是git pull -r或git pull --rebase。这样的好处很明显，提交记录会比较简洁。但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了，因为基底变了嘛，所以看个人需求了。
- 往公共分支上合代码的时候，使用merge。如果使用rebase，那么其他开发人员想看主分支的历史，就不是原来的历史了，历史已经被你篡改了。举个例子解释下，比如张三和李四从共同的节点拉出来开发，张三先开发完提交了两次然后merge上去了，李四后来开发完如果rebase上去（注意李四需要切换到自己本地的主分支，假设先pull了张三的最新改动下来，然后执行<git rebase 李四的开发分支>，然后再git push到远端），则李四的新提交变成了张三的新提交的新基底，本来李四的提交是最新的，结果最新的提交显示反而是张三的，就乱套了。
- 正因如此，大部分公司其实会禁用rebase，不管是拉代码还是push代码统一都使用merge，虽然会多出无意义的一条提交记录“Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序
