今天来介绍下 git 的 rebase 命令。这个命令是我进入新公司之后才了解到的，以前还真的没使用过，尽管我接触 git 已经有 3 年了。
假如现在有个项目，它的 git 状态是这样的：
OK，我们开始今天的内容。
分支合并
我们先在 master 分支的基础上新建一个 dev 分支, 并做一个 commit：
$(master) git checkout -b dev
这时候另外一个开发人员发现 master 上的代码有一个问题，对 master 的代码做了一个 fix，使得 master 的 head 向前推进了一步:
如果我们想将 master 的 Fix 改动应用到 dev 分支上，要如何做呢？
可以使用 merge，我们来试下：
$(dev) git merge master
merge 过后 dev 分支向前推进了一步。我们看下多出来的 commit 信息是怎样的
commit 02581b628586b29c5c8a3cfd04d1563fa4e5b5a7 (HEAD -> dev)
Merge: 18d26a0 8985e47
Author: lwhile <lwhile521@gmail.com>
Date: Sun Jun 3 15:26:55 2018 +0800
Merge branch 'master' into dev
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
commit 6639f35cc779afe6f7eb68f13faad0cfe2a8a7a4 (HEAD -> dev)
Author: lwhile <lwhile521@gmail.com>
Date: Sun Jun 3 16:01:29 2018 +0800
add dev3.go
commit c76ac0c0c0359170a6eca0ee1319ec16b2ae6351
Author: lwhile <lwhile521@gmail.com>
Date: Sun Jun 3 16:01:10 2018 +0800
add dev2.go
commit 20cd0cfcd64fee7c4459a1da527f8c2c239ac5e4
Author: lwhile <lwhile521@gmail.com>
Date: Sun Jun 3 16:00:57 2018 +0800
add dev1.go
提交完这 3 个 commit 之后，我们发现这 3 个 commit 属于同一个改动类型，完全没必要分成 3 个 commit。
那要怎么做呢？还是可以使用 rebase
$ (dev) git rebase -i HEAD~4
执行该命令 shell 会进入交互模式（-i）
pick c524f8e add dev.go
pick 20cd0cf add dev1.go
pick c76ac0c add dev2.go
pick 6639f35 add dev3.go
# Rebase df58ee3..6639f35 onto df58ee3 (4 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
根据提示，我们将文本做如下修改(将 pick 换成 s,至于为什么要这样写，可以看 git 的提示)：
pick c524f8e add dev.go
s 20cd0cf add dev1.go
s c76ac0c add dev2.go
s 6639f35 add dev3.go
保存并退出：
[detached HEAD 0a15d35] add dev.go
Date: Sun Jun 3 15:38:35 2018 +0800
4 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 dev.go
create mode 100644 dev1.go
create mode 100644 dev2.go
create mode 100644 dev3.go
Successfully rebased and updated refs/heads/dev.
现在 git 又进入了如下状态，只不过绿色的那个节点包含了 4 个 commit 信息
commit 0a15d3549ee9ec61ddeb33916c452fab2ad9b991 (HEAD -> dev)
Author: lwhile <lwhile521@gmail.com>
Date: Sun Jun 3 15:38:35 2018 +0800
add dev.go
add dev1.go
add dev2.go
add dev3.go
这时候再将 dev 合并进 master，commit 信息都会简洁很多，并且也有利于 review。
总结
rebase 是一个很神奇的工具，可以帮你做一些比较特别的改动。但要注意， rebase 是会隐藏你真实的修改记录的，所以最后呈现出来的 git 历史并不能表现你的真实操作，这点要注意。
