为什么网上说的git rebase 用法都这么复杂
git rebase 简明用法：把另一个分支的最新commit改变为当前分支的基础。
实现过程：在改动中会把不一致的本分支commit保存，把另一个分支的commit加载过来，然后把之前保存的commit打上新的时间戳放在后面。简称“变基”。
借用网上的图：
变基之前的分支
此时如用git merge命令：git checkout myworkgit merge origin会生成如下的树：
Merge 后的分支
如果用rebase：
git checkout myworkgit rebase origin把orgin的最新commit C4 作为当前分支mywork的基础，，则生成的树图示如下：
rebase后
这时C5和C6变成了新的C5′和C6′。
很明显rebase之后，分支树看起来更加清晰，把平行线变成了一条线，并省掉了一个merge自动产生的commit。缺点是rebase之后，当前分支之前的提交时间都变成rebase时的时间，提交历史发生了改变！简称穿越。如果在一个已经提交到远程仓库（只读）的分支上做rebase，导致本地commit和远程仓库不一致，就会产生很头痛的问题，因为一旦修改远程commit，已经下载了这些commit的同学就会凌乱。
所以，总结两点：
1. 在仅在需要rebase的时候rebase。
2. 仅在本地rebase时不会修改已经推送到远程仓库的commit的分支上做rebase。
这句话写出后我自己也晕了，其实都是自己先判断下，在本地分支和要rebase的分支的交点之后，本地分支没有任何远程分支的commit。
解决冲突：
git add .git rebase –continue
参考
一个人的期望值越大，心理承受力就会越小，就越经受不住失败的打击，
