rebase最佳实践
本文最后更新于:2022年4月15日 凌晨
rebase最常见的应用场景有两种,一是合并分支,做类似merge
的处理;二是合并commit,把多个commit合并为一个commit记录
一、合并分支
如下场景,你从master拉取了开发分支feature/A,在该分支上提交了两个commit: add d
和add e
。当你开发完时master多了一个同事的开发的c
功能的commit。这时可以使用rebase做变基处理
首先切换到master,把同事的代码更新拉取到本地
1 |
|
git pull有冲突就解决冲突
然后切回自己的开发分支feature/A,进行变基
1 |
|
变基具体做了什么呢?
实际上git
会先把feature/A上
的commit
与master
分支对比,把feature/A
上不同于master
的commit
取消掉,然后将其保存为patch
文件,存放在临时文件夹.git/rebase
下
然后把master分支上的commit合并到feature/A上
接着对.git/rebase
下的每个commit,逐个合并到feature/A上,每个commit的合入都可能有冲突,需要手动解决冲突。解决后执行一下命令,完成当前commit的合入。重复这个步骤知道所有commit都合入,就完成整个rebase过程了。
1 |
|
最终得到
二、合并commit
实际上,如果你的commit数量比较多,那么做rebase处理时可能会比较痛苦,尤其是多个commit中还对同一文件做了修改。
试想一下如下场景:
你在4个commit中都对a文件的同一处做了修改,如果a文件和远端master的代码有冲突,那么在rebase依次将commit合入的过程中,你需要解决4次冲突!
解决办法是在rebase远端master分支前,先把本地上的commit合并成一个commit
执行命令(commit id为你最早提交的commit的前一个commit的哈希值)
1 |
|
执行后进入vi编辑模式,默认情况下为p(pick),保留commit。把需要合并的改为s(squash),执行后就会打包成一个commit
1 |
|
你也可以直接指定合并最近的n次提交记录,效果和上面的是一样的。
1 |
|
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!