git rebase

基础

适用范围:

1. 作用:

• 合并两个分支, 并且不会留下合并提交记录

2. 场景:

• child::rebase无痕合并别人最新的commit

3. 不适用场景:

• 共享分支上不要用rebase
  • 即不要切换到共享分支上用rebase，但是别的分支rebase共享分支还是可以的（因为不会影响到目标分支）
• 当前分支已经落后于目标分支太久了
  • 因为rebase需要一个一个commit解决冲突，只要中间有一个冲突处理不好，则会影响后面所有的commit
  • 直接用merge更好

梗概:

• 指定某个提交记录为当前分支的基, 旧的基就变成两个分支的公共部分
  • 简而言之, 就是改变两条分支的分叉点
• 只影响当前分支，不影响目标分支

rebase的机制

• 把当前分支基前面的提交全部暂时移除，这时当前分支头指向旧基
• 把指定的分支的提交拉进当前分支的顶部，产生新基
• 把原来移除的commit逐个进行提交，遇到冲突时，修改原来的commit，以处理冲突

对远程仓库的影响

• rebase就会导致本地与远程分支分散
  • pull分散的分支实际上就相当于git merge 远程分支
  • 所以一般rebase后会使用git push的—force-with-lease模式将本地分支覆盖到远程分支

当别的分支基于的分支被rebase之后

child::当基础分支被rebase变更后

处理冲突

• 当前分支rebase别的分支的时候，在新基的基础上提交第一个commit的时候，发生了冲突
  • 这时current是新基，incoming是本来有的第一个commit
  • rebase是用来与目标分支保持同步，rebase前不要提前在当前分支上commit来手动保持同步

示例

• 当前feat分支做了一些功能，但别人已经帮自己做了一些功能，并提前合到master分支上了
• 这时就不要在当前分支上revert自己做过的一些功能了
• 这时应该通过git 合并分支，把master分支合进来
  • 如果选择rebase合并，则在相同的功能上出现冲突的时候，current是master的head，incoming是自己分支上的提交（即自己那未完成的功能）
  • 以master为准，修改自己的commit，这样一条一条的处理冲突
    • 所以其实这种情况最好还是使用merge

操作:

1. 在图形化git工具上:

• child::GitKraken

实例

示例之一

child::

git rebase实验1

两个分支rebase前的情况

1. master分支rebase到test3提交的情况

2. A分支rebase到test5提交的情况

三个共基分支

1. 未rebase之前

2. master分支rebase到test3提交

指向原始笔记的链接