git rebase 使用总结

今天来介绍下 git 的 rebase 命令。这个命令是我进入新公司以后才了解到的，之前还真的没使用过，尽管我接触 git 已经有 3 年了。

假如如今有个项目，它的 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）