git rebase

rebase：
变基，意即改变分支的根基
变基会遇到两种情况：
fast-forward: 这是一定不会发生冲突
non-fast-forward: 可能发生冲突, 可能不会
b想变基到a分支，在a分支上执行 git rebase b
冲突：
有冲突时，必须先手工处理冲突
之后git add .标记为处理完毕
再git rebase --contine完成变基
(跟git merge后的处理不一样,在git add .处理完冲突后不是git commit)

git rebase操作实际上是将当前执行rebase分支的所有基于原分支提交点之后的commit打散成一个一个的patch，
并重新生成一个新的commit hash值，
再次基于原分支目前最新的commit点上进行提交，
并不根据两个分支上实际的每次提交的时间点排序，
rebase完成后，
切到基分支进行合并另一个分支时也不会生成一个新的commit点，可以保持整个分支树的完美线性

当我们开发一个功能时，可能会在本地有无数次commit，
而你实际上在你的master分支上只想显示每一个功能测试完成后的一次完整提交记录就好了，
其他的提交记录并不想将来全部保留在你的master分支上，
那么rebase将会是一个好的选择，
他可以在rebase时将本地多次的commit合并成一个commit，还可以修改commit的描述等

前提假设：
假定，从 origin 拉出一个分支 mywork
现将 mywork 的部分提交合入 origin

命令操作(main_dev 合入 main)：
git add .
git commit -m "在 main_dev 上的修改"
git rebase main // 此步骤可省略？

git checkout main
git rebase main_dev // 此时，main_dev 变基到了main

git push

注意：上述分支提交时未 push，只有切换到主分支rebase完成后才push

 

 

 

 

简单说相当于将 mywork 分支的所有提交点从最开始提交点移到了master的最新提交点进行合并
新生成的记录就不是按提交的先后顺序排序了

rebase注意事项
rebase过程中也会出现冲突
解决冲突后，使用git add添加，然后执行
git rebase - - continue
接下来Git会继续应⽤用余下的补丁
任何时候都可以通过如下命令终止rebase，分支会恢复到rebase开始前的状态
git rebase - - abort

rebase最佳实践
不要对master分支执⾏行rebase，否则会引起很多问题
一般来说，执行rebase的分支都是自己的本地分支，没有推送到远程版本库

参考：https://blog.csdn.net/wzq6578702/article/details/76727740