git rebase
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了git rebase相关的知识,希望对你有一定的参考价值。
参考技术A 在上一节我们看到了,多人在同一个分支上协作时,很容易出现冲突。即使没有冲突,后push的童鞋不得不先pull,在本地合并,然后才能push成功。每次合并再push后,分支变成了这样:
总之看上去很乱,有强迫症的童鞋会问:为什么Git的提交历史不能是一条干净的直线?
其实是可以做到的!
Git有一种称为rebase的操作,有人把它翻译成“变基”。
[图片上传失败...(image-78f8b1-1615360358168)]
先不要随意展开想象。我们还是从实际问题出发,看看怎么把分叉的提交变成直线。
在和远程分支同步后,我们对 hello.py 这个文件做了两次提交。用 git log 命令看看:
注意到Git用 (HEAD -> master) 和 (origin/master) 标识出当前分支的HEAD和远程origin的位置分别是 582d922 add author 和 d1be385 init hello ,本地分支比远程分支快两个提交。
现在我们尝试推送本地分支:
很不幸,失败了,这说明有人先于我们推送了远程分支。按照经验,先pull一下:
再用 git status 看看状态:
加上刚才合并的提交,现在我们本地分支比远程分支超前3个提交。
用 git log 看看:
对强迫症童鞋来说,现在事情有点不对头,提交历史分叉了。如果现在把本地分支push到远程,有没有问题?
有!
什么问题?
不好看!
有没有解决方法?
有!
这个时候,rebase就派上了用场。我们输入命令 git rebase 试试:
输出了一大堆操作,到底是啥效果?再用 git log 看看:
原本分叉的提交现在变成一条直线了!这种神奇的操作是怎么实现的?其实原理非常简单。我们注意观察,发现Git把我们本地的提交“挪动”了位置,放到了 f005ed4 (origin/master) set exit=1 之后,这样,整个提交历史就成了一条直线。rebase操作前后,最终的提交内容是一致的,但是,我们本地的commit修改内容已经变化了,它们的修改不再基于 d1be385 init hello ,而是基于 f005ed4 (origin/master) set exit=1 ,但最后的提交 7e61ed4 内容是一致的。
这就是rebase操作的特点:把分叉的提交历史“整理”成一条直线,看上去更直观。缺点是本地的分叉提交已经被修改过了。
最后,通过push操作把本地分支推送到远程:
再用 git log 看看效果:
远程分支的提交历史也是一条直线。
Git: git rebase 用法小结 (转)
本文转自:【Git】rebase 用法小结
rebase在git中是一个非常有魅力的命令,使用得当会极大提高自己的工作效率;相反,如果乱用,会给团队中其他人带来麻烦。它的作用简要概括为:可以对某一段线性提交历史进行编辑、删除、复制、粘贴;因此,合理使用rebase命令可以使我们的提交历史干净、简洁!
前提:不要通过rebase对任何已经提交到公共仓库中的commit进行修改(你自己一个人玩的分支除外)
1. 合并多个commit为一个完整commit
当我们在本地仓库中提交了多次,在我们把本地提交push到公共仓库中之前,为了让提交记录更简洁明了,我们希望把如下分支B、C、D三个提交记录合并为一个完整的提交,然后再push到公共仓库。
现在我们在测试分支上添加了四次提交,我们的目标是把最后三个提交合并为一个提交:
这里我们使用命令:
git rebase -i [startpoint] [endpoint]
其中-i的意思是--interactive,即弹出交互式的界面让用户编辑完成合并操作,[startpoint] [endpoint]则指定了一个编辑区间,如果不指定[endpoint],则该区间的终点默认是当前分支HEAD所指向的commit(注:该区间指定的是一个前开后闭的区间)。
“前开后闭”是什么意思呢,就是合并的区间不包含[startpoint]那次的提交,但是包含[endpoint]那次的提交。
在查看到了log日志后,我们运行以下命令:
git rebase -i 36224db
或
git rebase -i HEAD~3
然后我们会看到如下界面:
上面未被注释的部分列出的是我们本次rebase操作包含的所有提交,下面注释部分是git为我们提供的命令说明。每一个commit id 前面的pick表示指令类型,git 为我们提供了以下几个命令:
- pick:保留该commit(缩写:p)
- reword:保留该commit,但我需要修改该commit的注释(缩写:r)
- edit:保留该commit, 但我要停下来修改该提交(不仅仅修改注释)(缩写:e)
- squash:将该commit和前一个commit合并(缩写:s)
- fixup:将该commit和前一个commit合并,但我不要保留该提交的注释信息(缩写:f)
- exec:执行shell命令(缩写:x)
- drop:我要丢弃该commit(缩写:d)
根据我们的需求,我们将commit内容编辑如下:
然后是注释修改界面:
编辑完保存即可完成commit的合并了:
2. 将某一段commit粘贴到另一个分支上
当我们项目中存在多个分支,有时候我们需要将某一个分支中的一段提交同时应用到其他分支中,就像下图:
我们希望将develop分支中的C~E部分复制到master分支中,这时我们就可以通过rebase命令来实现(如果只是复制某一两个提交到其他分支,建议使用更简单的命令:git cherry-pick
)。
master分支:
我们使用命令的形式为:
git rebase [startpoint] [endpoint] --onto [branchName]
其中,[startpoint] [endpoint]仍然和上一个命令一样指定了一个编辑区间(前开后闭),--onto的意思是要将该指定的提交复制到哪个分支上。
所以,在找到C(90bc0045b)和E(5de0da9f2)的提交id后,我们运行以下命令:
git rebase 90bc0045b^ 5de0da9f2 --onto master
注:因为[startpoint] [endpoint]指定的是一个前开后闭的区间,为了让这个区间包含C提交,我们将区间起始点向后退了一步。
运行完成后查看当前分支的日志:
可以看到,C~E部分的提交内容已经复制到了G的后面了,大功告成?NO!我们看一下当前分支的状态:
当前HEAD处于游离状态,实际上,此时所有分支的状态应该是这样:
所以,虽然此时HEAD所指向的内容正是我们所需要的,但是master分支是没有任何变化的,git只是将C~E部分的提交内容复制一份粘贴到了master所指向的提交后面,我们需要做的就是将master所指向的提交id设置为当前HEAD所指向的提交id就可以了,即:
git checkout master
git reset --hard 0c72e64
此时我们才大功告成!
以上是关于git rebase的主要内容,如果未能解决你的问题,请参考以下文章
Git 常用操作 - git clone/git checkout -b/git diff/git push/git pull