前言
最近在研究协同的底层实现，其中提到类git的rebase机制也属于其中方案之一。用户在不同终端执行操作最终通过rebase合成有序的节点。
- 服务端唯一确定operation顺序，在各个客户端rebase后应用
- 需依赖中心节点，亦不便支持离线编辑
探讨git rebase
在日常开发中往往都会采用多人写作开发模式，但我们想将某人的更新合并到自己分支时，我们有两个选择:合并（merge）和变基（rebase）这两种的工作方式截然不同。
-
合并(merge)
合并会从另外一个分支获取更改，并且创建一个包含这些更改的新提交到目标分支，某种程度上 合并就像我们在目标分支做了这些更改并且提交了这些更改一样，会产生新的提交节点 -
变基（rebase）
当我们将一个分支rebase到另外一个分支时，git会将整个分支的基点更改作为新提交，就好像我们在目标分支的最新更改开始工作一样。它会获取该分支的所有提交，并开始将他们逐一应用到目标分支,从而修改git分支历史记录
- git rebase的使用
执行git pull --rebase时需要保证本地目录干净(不能存在modified的文件，存在Untracked files是可以的)
# 以rebase的方式拉取远程改动
git pull --rebase
# 遇到冲突时，可以手动解决冲突后继续rebase也可以放弃本次rebase
1.解决冲突
git add . # 手动解决完冲突的所有文件
git rebase --continue # 继续rebase直到没有冲突
2. 放弃本次rebase操作
git rebase --abort
# rebase完成之后进行提交
git push --force-with-lease
注意： 在提交push时推荐--force-with-lease而不是--force为什么呢？
因为--force-with-lease会检查远程分支的更改，假设A和B正在同一个feature分支工作，B推送了一个提交此时A在rebase其本地分支，尝试直接push会被拒接，A会认为则是由于reabse造成的，并使用了--force导致了B的所有更改被重写掉了(B的所有改变将被丢弃了)，而使用--force-with-lease会接收到一个警告，提示远程分支存在其他人的提交
-
git rebase的优点
它以线性方式保存git的历史记录，再使用rebase时不会产生任何不必要的提交节点 -
git rebase的其他应用
# 将最新commit~ commitId的更改合并成一个commit。 在回滚时有用
git rebase -i commitId
