前言
哈喽，everybody，不知不觉8天的小长假也接近了尾声，玩耍了这么多天，今天也要收一收心，开始学习了呦～。明天就要上班啦，今天姐姐突然问我git-rebase指令是干什么的，怎么用？其实我是不想给他讲的，但是还是没有逃过姐姐的软磨硬泡，那么我们就一起来看一看什么是git-rebase吧！！！
缘起
话说，我和姐姐的缘分是在那一个月黑风高的晚上，啪，姐姐一巴掌打在了我的脸上并说了一句：能不能讲重点～～～。哈哈，不开玩笑了，直接说重点吧。我们先来看一个场景，我查看了一下我github上的个人仓库，commit提交次数很多，提交内容如下：
这么多的提交，有很多没有规范的命名，因为是自己使用，就随便开整了，这确实不好，还有一些没有必要的提交，其实是可以合并到一起的，这样会导致如下问题：
- 造成分支污染，项目中充满了许多
commit记录，当出现紧急问题需要回滚代码时，就只能一条条的查看了。 - 代码
review不方便，当你要做code review时，一个很小的功能却提交了很多次，看起来就不是很方便了。
这一篇文章我们先不讲git提交规范，我们先来解决一下如何合并多次提交记录。
rebase作用一：合并提交记录
通过上面的场景，我们可以引申出git-rebase的第一个作用：合并提交记录。现在我们想合并最近5次的提交记录，执行：
$ git rebase -i HEAD~2执行该指令后会自动弹出vim编辑模式：
pick e2c71c6 update readme
pick 3d2c660 wip: merge`
# Rebase 5f47a82..3d2c660 onto 5f47a82 (2 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
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop = remove commit
# l, label 从这里我们可以看出前面5行是我们要合并的记录，不过前面都带了一个相同的指令：pick，这是什么指令呢，不要慌，这不，下面已经给出了commands:
pick：保留该commit（缩写:p）
reword：保留该commit，但我需要修改该commit的注释（缩写:r）
edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
squash：将该commit和前一个commit合并（缩写:s）
fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）
exec：执行shell命令（缩写:x）
drop：我要丢弃该commit（缩写:d）
label：用名称标记当前HEAD(缩写:l)
reset：将HEAD重置为标签(缩写:t)
merge：创建一个合并分支并使用原版分支的commit的注释(缩写:m)根据这些指令，我们可以进行修改，如下：
pick e2c71c6 update readme
s 3d2c660 wip: merge`修改好后，我们点击保存退出，就会进入注释界面:
# This is a combination of 2 commits.
# This is the 1st commit message:
update readme
# This is the commit message #2:
wip: merge`
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Thu Sep 17 22:03:52 2020 +0800
#
# interactive rebase in progress; onto 5f47a82
# Last commands done (2 commands done):
# pick e2c71c6 update readme
# squash 3d2c660 wip: merge`
# No commands remaining.
# You are currently rebasing branch 'master' on '5f47a82'.
#
# Changes to be committed:
# new file: hash/.idea/.gitignore
# new file: hash/.idea/hash.iml
# new file: hash/.idea/misc.xml
# new file: hash/.idea/modules.xml
# new file: hash/.idea/vcs.xml
# new file: hash/go.mod
# new file: hash/hash/main.go
# modified: snowFlake/Readme.md上面把每一次的提交的meassage都列出了，因为我们要合并这两次的commit，所以提交注释可以修改成一条，最终编辑如下：
# This is a combination of 2 commits.
# This is the 1st commit message:
fix: merge update and wip: merge`
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Thu Sep 17 22:03:52 2020 +0800
#
# interactive rebase in progress; onto 5f47a82
# Last commands done (2 commands done):
# pick e2c71c6 update readme
# squash 3d2c660 wip: merge`
# No commands remaining.
# You are currently rebasing branch 'master' on '5f47a82'.
#
# Changes to be committed:
# new file: hash/.idea/.gitignore
# new file: hash/.idea/hash.iml
# new file: hash/.idea/misc.xml
# new file: hash/.idea/modules.xml
# new file: hash/.idea/vcs.xml
# new file: hash/go.mod
# new file: hash/hash/main.go
# modified: snowFlake/Readme.md编辑好后，保存退出就可以了。这样就完成了一次合并commit。我们来验证一下：
$ git log
15ace34 (HEAD -> master) fix: merge update and wip: merge`
5f47a82 update snowFlake code从这里我们可以看到，两次提交变成了一次，减少了无用的提交信息。
作用二：分支合并
这个作用我们使用的很少，但是还是要知道，下面我们一起来看一下使用场景。
假设我们现在有一个新项目，现在我们要从master分支切出来一个dev分支，进行开发：
$ git checkout -b dev这时候，你的同事完成了一次 hotfix，并合并入了 master 分支，此时 master 已经领先于你的 dev 分支了：
同事修复完事后，在群里通知了一声，正好是你需要的部分，所以我们现在要同步master分支的改动，使用merge进行合并：
$ git merge master
图中绿色的点就是我们合并之后的结果，执行git log就会在记录里发现一些 merge 的信息，但是我们觉得这样污染了 commit 记录，想要保持一份干净的 commit，怎么办呢？这时候，git rebase 就派上用场了。
所以现在我们来试一试使用git rebase，我们先回退到同事 hotfix 后合并 master 的步骤，我现在不使用merge进行合并了，直接使用rebase指令
$ git rebase master这时，git会把dev分支里面的每个commit取消掉，然后把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；然后，把 dev 分支更新到最新的 master 分支；最后，把上面保存的 patch 文件应用到 dev 分支上；
从 commit 记录我们可以看出来，dev 分支是基于 hotfix 合并后的 master ，自然而然的成为了最领先的分支，而且没有 merge 的 commit 记录，是不是感觉很舒服了。
我们在使用rebase合并分支时，也会出现conflict，在这种情况下，git 会停止 rebase 并会让你去解决冲突。在解决完冲突后，用 git add 命令去更新这些内容。然后再次执行git rebase --continue，这样git 会继续应用余下的 patch 补丁文件。
假如我们现在不想在执行这次rebase操作了，都可以通过--abort回到开始前状态：
git rebase --abortrebase是存在危险的操作 - 慎用
我们现在使用rebase操作看起来是完美的，但是他也是存在一定危险的，下面我们就一起来看一看。
现在假设我们在dev分支进行开发，执行了rebase操作后，在提交代码到远程之前，是这样的：
提交dev分支到远程代码仓库后，就变成了这样：
而此时你的同事也在 dev 上开发，他的分支依然还是以前的dev，并没有进行同步master：
那么当他 pull 远程 master 的时候，就会有丢失提交纪录。这就是为什么我们经常听到有人说 git rebase 是一个危险命令，因为它改变了历史，我们应该谨慎使用。
不过，如果你的分支上需要 rebase 的所有 commits 历史还没有被 push 过，就可以安全地使用 git-rebase来操作。
总结
在asong的细心讲解下，姐姐完全搞懂了怎么使用git rebase，我们来看一下姐姐的总结：
- 当我们在一个过时的分支上面开发的时候，执行
rebase以此同步master分支最新变动； - 假如我们要启动一个放置了很久的并行工作，现在有时间来继续这件事情，很显然这个分支已经落后了。这时候需要在最新的基准上面开始工作，所以
rebase是最合适的选择。 git-rebase很完美，解决了我们的两个问题：- 合并
commit记录，保持分支整洁； - 相比
merge来说会减少分支合并的记录；
- 合并
- 使用
rebase操作要注意一个问题，如果你的分支上需要rebase的所有commits历史还没有被push过，就可以安全地使用git-rebase来操作。
看来姐姐是真的学会了，那你们呢？
没有学会不要紧，亲自试验一下才能更好的理解呦～～～。
好啦这一篇文章到这里就结束了，我们下期见。
结尾给大家发一个小福利吧，最近我在看[微服务架构设计模式]这一本书，讲的很好，自己也收集了一本PDF，有需要的小伙可以到自行下载。获取方式：关注公众号：[Golang梦工厂]，后台回复：[微服务]，即可获取。
我翻译了一份GIN中文文档，会定期进行维护，有需要的小伙伴后台回复[gin]即可下载。
我是asong，一名普普通通的程序猿，让我一起慢慢变强吧。我自己建了一个golang交流群，有需要的小伙伴加我vx,我拉你入群。欢迎各位的关注，我们下期见~~~
推荐往期文章：
- 手把手教姐姐写消息队列
- 详解Context包，看这一篇就够了！！！
- go-ElasticSearch入门看这一篇就够了(一)
- 面试官：go中for-range使用过吗？这几个问题你能解释一下原因吗
- 学会wire依赖注入、cron定时任务其实就这么简单！
- 听说你还不会jwt和swagger-饭我都不吃了带着实践项目我就来了
- 掌握这些Go语言特性，你的水平将提高N个档次(二)
- go实现多人聊天室，在这里你想聊什么都可以的啦！！！
- grpc实践-学会grpc就是这么简单
- go标准库rpc实践
- 2020最新Gin框架中文文档 asong又捡起来了英语，用心翻译
- 基于gin的几种热加载方式
- boss: 这小子还不会使用validator库进行数据校验，开了～～～