概念
- 当执行rebase操作时，git会从两个分支的共同祖先开始提取待变基分支上的修改
- 然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用到基分支的最新提交的后面
- 相比merge会减少一些分支合并记录
- feature：待变基分支、当前分支
- master：基分支、目标分支
用法
1、常见命令
命令 缩写 含义
pick p 保留该commit
reword r 保留该commit，但需要修改该commit的注释
edit e 保留该commit, 但我要停下来修改该提交(不仅仅修改注释)
squash s 将该commit合并到前一个commit
fixup f 将该commit合并到前一个commit，但不要保留该提交的注释信息
exec x 执行shell命令
drop d 丢弃该commit
i 合并当前分支的多个commit记录
2、解决冲突
- git rebase --skip
抛弃本地的 commit，采用远程的 commit。慎用：因为你本地的修改都会失去。
- git rebase --abort
效果是：终止这次 rebase 操作
- git rebase --continue
手动处理冲突的文件：执行git add .，再 git rebase --continue
反复操作直到解决完所有冲突，并合并到分支上。
3、其他
- git pull -- rebase
拉取代码减少不必要的 merge commit
注意事项
1、不要基于rebase的分支 切新分支
如果feature在写完新需求b后, 切了新分支 feature_B, 然后又rebase了develop, 那么新分支feature_B无论是合进develop 还是 合进 feature 都会有冲突, 出现重复的b(其实是b和b’)
2、不要对已经合并到主分支的本地修改进行变基
自己的分支, 如果想对已经推送的commit进行修改, 可以在修改完后, 使用 git push -f 强行push并覆盖远程对应分支。
但是如果这些修改 已经被合到了其他分支(比如主分支), 那又会出现冲突, 因为其他分支保存的是你rebase之前 合进去的commit
3、不要在预发布/正式分支上使用rebase -i
变基那个节点开始往后的所有节点的commit id 都会发生变化，master上有100个commit, 你悄悄改了第50个commit, 那从50—100的所有commit全部改变了, 这时, 别人的分支合进来, 就会有51个冲突
