git：详解git rebase命令
背景
今天无意中打开 git 官网，发现 git 命令还是很多的，然而我们常用的就那几个，今天来学习一个也不怎么常用的命令 rebase
官网链接
都说学一个东西最好的方式就是读他的 官方文档，这里我读了一遍，把一些核心的地方整理成这篇 blog
为什么要出现git rebase
首先可以看到，rebase 是属于 Patching 这一类下面的，也就是补丁
我们平常协同开发基本上都是基于 master 自己拉一个分支，然后发布的时候把各自的分支合并到 master 进行发布，这样做有一些的缺陷：
- 当你 merge 了一个比较大的改动，时间线拖得比较长，这时候你 merge 到 master 后，看 master 的提交记录，会有很多别人的提交记录和你的混在一起。
命令
全部命令：
git rebase [-i | --interactive] [<options>] [--exec <cmd>][--onto <newbase> | --keep-base] [<upstream> [<branch>]]git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]--root [<branch>]git rebase (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch)
常用命令：
发起合并
# 比如要把topic的分支变基到master上，则先切到topic，然后执行
git rebase master
# 或者
git rebase master topic
git pull master --rebase
# 分解为如下，也就是把远程的master作为基地
git fetch master
git rebase master
解决冲突
# 放弃合并，回到rebase操作之前的状态
git rebase --abort
# 则会将引起冲突的commits丢弃掉（慎用！！）
git rebase --skip
# 合并冲突，结合"git add 文件"命令一起用与修复冲突，提示开发者，一步一步地有没有解决冲突。
git rebase --continue
合并提交
# 将多个提交合并为一次提交
git rebase -i HEAD~2
作用一：分支合并
按照这个建立分支
A---B---C topic/
D---E---F---G master
在 topic 分支执行 git rebase mater，如果没有冲突，则会变成这样
作用二：合并多个提交
必须在你的 commit push 到远端之前使用
git rebase -i HEAD~2
这里的 HEAD~2 代表回退两个commit，具体可以看 这篇文章
reabase原理
- git 会把 feature1 分支里面的每个 commit 取消掉；
- 把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
- 把 feature1 分支更新到最新的 master 分支；
- 把上面保存的 patch 文件应用到 feature1 分支上。
冲突处理
执行 rebase 后可能会出现冲突，解决冲突后
git add .
# 注意，这里无需执行 git commit
git rebase --continue
这样 git 会继续应用余下的 patch 补丁文件，所以有可能你会处理多次冲突。
在任何时候，我们都可以用 --abort 参数来终止 rebase 的行动
git rebase --abort
优缺点
优点：
- 分支干净
缺点：
- 篡改记录
正因如此，大部分公司其实会禁用rebase，不管是拉代码还是push代码统一都使用merge，虽然会多出无意义的一条提交记录“Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序