rebase其实就是一种分支级别的遴选
从一个常见情景开始
如图所示
每个灰色的节点都为一个独立的commit
绿色表示本地分支的引用，红色表示远程分支的引用
首先，一般来说，git希望你只在本地分支做rebase操作，因为rebase本质上会改变分支的提交记录，但这里的关键并非远程跟本地的问题，而是该分支是否是一个协同分支的问题，如果分支本身为某一个单一作者所有并且不会有其他成员参与，你完全可以用rebase来进行操作，毕竟谁也不想写的本地代码因为电脑故障而丢失，所以提交完后顺便推送到远程是常见的操作
假设HEAD提交了一个空白文件info.txt
A表示在info.txt追加A字符并换行
B表示在info.txt追加B字符并换行
C，D同理
master的HEAD指向B，info.txt包含的内容就是
bash
A
Bf1的HEAD指向D，info.txt包含的内容就是
bash
C
D假设f1想要更新下master的代码
如果不考虑rebase的方式，它有二种方式去实现
- 直接merge master的代码，这种是最直接的方式，但是坏处在于会产生一个合并的节点，提交记录非线性，不直接
- 使用cherry pick, 去cherry pick A，B，这样能保持提交记录的线性，但是一两个节点还好说，节点多的话，一个个cherry pick 容易出现疏漏，并且如果按照表述逻辑，应该是C，D处于，A，B节点的后面，这样也方便后续开发E，F的时候，可以连贯起来不会出现C，D，A，B，E，F，后续也不好跟踪自己的模块代码提交记录
正确的方式应该是
-
git checkout -b temp origin/master从master checkout出一个临时分支 -
git cherry-pick C
-
解冲突 continue
-
git cherry pick D
-
这里因为保留了C的更改，所以没有冲突
-
git push -f origin temp:f1强制将临时分支推送到f1
此时你的f1分支的远程提交记录就是A-B-C-D
如果你要同步到本地 f1，此时还需要强制拉取远端代码，因为远程提交记录被强制修改，与本地的提交记录产生分支
git chekcout f1git reset --hard origin/f1
而以上的所有步骤其实只要一个命令就可以解决
git rebase master
需要注意的问题
常常发生在本地分支已经上传到本地的情景
在不了解rebase原理以及一直都是merge使用者会出现的问题就是在rebase完成后，
看到终端提示pull的时候，直接pull，相当于rebase origin 远端的代码解冲突
正确的做法就是rebase完成后，做一次远程的强制push
git push origin --force
同步本地跟远端的代码