Git rebase命令的使用
- rebase可以将某个目标分支上的提交作为基础，并将当前分支与目标分支不同的提交合并后放到后面
- 合并完成后，commit的名称不变，但hash值发生了变化
- 可视化描述：
- master分支开始创建两个分支A，B
- 分支A: master->A1->A2-A3
- 分支B: master->B1->B2
- 在分支A上rebase目标分支B执行
git rebase B - 解决冲突【缺陷是这里的分支冲突好像无法使用IDEA的工具检查，只能自己搜索查看】
- rebase时
git rebase target_branch会一个个文件出现冲突 - 使用
git rebase --skip可以跳过当前冲突对应的文件的当前分支的修改，保留别人target_branch的修改，慎用
- rebase时
- 解决冲突的文件使用
git add file或者git rm file标记为已解决 - 所有文件都解决以后使用
git rebase --continue完成rebase操作【注意，这个过程不可逆，不像merge一样可以回退】- 解决冲突并
git rebase --continue后会出现下一个冲突，直到没有冲突
- 解决冲突并
- 此时的分支情况
- 分支A: master->B1->B2->A1’->A2’-A3’
- A1’和A1 commit的名称相同，但是hash值不同，已经不是同一个提交了，是融合了B1,B2的提交
- A2’和A2 以及 A3’和A3 commit的情况相似
- 分支B: master->B1->B2
- 分支A: master->B1->B2->A1’->A2’-A3’
- 中途取消rebase操作可以使用
git rebase --abort回退到原始分支的【但一旦git rebase --continue提交成功后无法回退】
rebase和merge的区别
- rebase
- 操作后当前分支的commit【从相同commit开始往后的】都被修改了，所以无法回退到当前分支和目标分支的交叉之间的commit
- 在version control工具上看不出来是哪些线合并的，只保留一条线，看起来就像是从未有过分支一样
- rebase时
git rebase target_branch会一个个文件出现冲突，解决冲突并git rebase --continue后会出现下一个，直到全部完成，而merge时git merge target_branch是所有文件的冲突一起出现的
- merge
- 操作后是保留了所有分支的commit，新创建了一个commit用于合并分支，还能从当前分支回退到之前的版本
- 在version control工具上看起来就是两条线合并到了一起
- 如果想使用IDEA进行冲突解决，需要从IDEA上提交rebase或merge请求