git rebase 使用总结
Posted cangqinglang
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了git rebase 使用总结相关的知识,希望对你有一定的参考价值。
今天来介绍下 git 的 rebase 命令。
假如现在有个项目,它的 git 状态是这样的:
这是背景,接下来我们正式开始今天的内容。
分支合并
我们先在 master 分支的基础上新建一个 dev 分支, 并做一个 commit:
> $(master) git checkout -b dev
这时候另外一个开发人员发现 master 上的代码有一个问题,对 master 的代码做了一个 fix,使得 master 的 head 向前推进了一步:
如果我们想将 master 的 Fix 改动应用到 dev 分支上,要如何做呢?
可以使用 merge,我们来试下:
$(dev) git merge master
merge 过后 dev 分支向前推进了一步。我们看下多出来的 commit 信息是怎样的
dev 上 多出来的这个 commit(绿色的那个节点), 就是我们的 merge 信息。
有时候我们并不想要 git 记录这个 merge 信息,因为让 git 的历史记录变得很繁琐,要如何做呢?可以使用 rebase !
我们先回到 master 提交了 fix 之后的 git 状态:
执行 rebase 命令:
$ (dev) git rebase master
这时候看下 git 状态:
比较下 merge 和 rebase 之后的状态图,我们可以发现 masste 的 fix 被接到 dev 的后面,并且没有多出一个 merge 信息。这样 commit 信息是不是简洁了很多?
commit 改写
除了用在分支的合并上, rebase 命令还能帮你修改 commit 记录。
我们让 dev 分支再向前推进 3 步:
╰─$ git log
提交完这 3 个 commit 之后,我们发现这 3 个 commit 属于同一个改动类型,完全没必要分成 3 个 commit。
那要怎么做呢?还是可以使用 rebase
$ (dev) git rebase -i HEAD~4
执行该命令 shell 会进入交互模式(-i)
根据提示,我们将文本做如下修改(将 pick 换成 s,至于为什么要这样写,可以看 git 的提示):
保存并退出:
现在 git 又进入了如下状态,只不过绿色的那个节点包含了 4 个 commit 信息
commit 0a15d3549ee9ec61ddeb33916c452fab2ad9b991 (HEAD -> dev)
这时候再将 dev 合并进 master,commit 信息都会简洁很多,并且也有利于 review。
总结
rebase 是一个很神奇的工具,可以帮你做一些比较特别的改动。但要注意, rebase 是会隐藏你真实的修改记录的,所以最后呈现出来的 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)
以上是关于git rebase 使用总结的主要内容,如果未能解决你的问题,请参考以下文章