Git使用git rebase：合并提交合并分支

淩亂°似流年 2022-10-20 12:15 398阅读 0赞

## rebase作用一：合并提交记录 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1amlhbjk1NDQ_size_16_color_FFFFFF_t_70][]

合并提交记录。现在我们想合并最近2次的提交记录，执行：

$ git rebase -i HEAD~2
    
    弹出
    pick e2c71c6 update readme
    pick 3d2c660 wip: merge`
    
    # Rebase 5f47a82..3d2c660 onto 5f47a82 (2 commands)

前面都带了一个相同的指令：pick，这是什么指令呢
    
    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`

上面把每一次的提交的`meassage`都列出了，因为我们要合并这两次的`commit`，所以提交注释可以修改成一条，最终编辑如下：

# This is a combination of 2 commits.
    # This is the 1st commit message:
    
    fix: merge update and wip: merge`

编辑好后，保存退出就可以了。这样就完成了一次合并`commit`。我们来验证一下：

$ git log
    15ace34 (HEAD -> master) fix: merge update and wip: merge`
    5f47a82 update snowFlake code

从这里我们可以看到，两次提交变成了一次，减少了无用的提交信息。

## 作用二：分支合并 ##

新建一个开发分支  git checkout -b dev

这时候，你的同事完成了一次 `hotfix`，并合并入了 `master` 分支，此时 `master` 已经领先于你的 `dev` 分支了：

![4f45e9e207ffa91ad1dc8d13c4ea8e3d.png][]

同事修复完事后，在群里通知了一声，正好是你需要的部分，所以我们现在要同步`master`分支的改动，使用`merge`进行合并：

git merge master

![424599a38ddbbd99ecd7a282a63d2650.png][]

图中绿色的点就是我们合并之后的结果，执行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` 分支上；

![6bfb435f06ab1aa54dfa87ed2d5fa790.png][]

从 commit 记录我们可以看出来，dev 分支是基于 hotfix 合并后的 master ，自然而然的成为了最领先的分支，而且没有 merge 的 commit 记录，是不是感觉很舒服了。

我们在使用rebase合并分支时，也会出现conflict，在这种情况下，git 会停止 rebase 并会让你去解决冲突。

在解决完冲突后，用 git add 命令去更新这些内容。然后再次执行git rebase --continue，这样git 会继续应用余下的 patch 补丁文件。

假如我们现在不想在执行这次rebase操作了，都可以通过--abort回到开始前状态：

git rebase --abort

`rebase`是存在危险的操作 - 慎用

我们现在使用`rebase`操作看起来是完美的，但是他也是存在一定危险的，下面我们就一起来看一看。

现在假设我们在`dev`分支进行开发，执行了`rebase`操作后，在提交代码到远程之前，是这样的：

![d7ab69d555c0602afcc837211a9b9fdb.png][]

提交`dev`分支到远程代码仓库后，就变成了这样：

![fb7b4c1ec703522c511796a068ca26d9.png][]

而此时你的同事也在 `dev` 上开发，他的分支依然还是以前的`dev`，并没有进行同步`master`：

![353d77e73f09dfbad29841238a94eefe.png][]

那么当他 pull 远程 master 的时候，就会有丢失提交纪录。这就是为什么我们经常听到有人说 git rebase 是一个危险命令，因为它改变了历史，我们应该谨慎使用。

不过，如果你的分支上需要 rebase 的所有 commits 历史还没有被 push 过，就可以安全地使用 git-rebase来操作。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1amlhbjk1NDQ_size_16_color_FFFFFF_t_70]: /images/20221020/e813710f4024495fa40319075ccaf69b.png
[4f45e9e207ffa91ad1dc8d13c4ea8e3d.png]: /images/20221020/b688fb2d29864132adc0ea494e00c466.png
[424599a38ddbbd99ecd7a282a63d2650.png]: /images/20221020/1150e1d52b8745be96424b718f26ff5a.png
[6bfb435f06ab1aa54dfa87ed2d5fa790.png]: /images/20221020/a5035a6983b14dbfa321ad73d6eaa3a6.png
[d7ab69d555c0602afcc837211a9b9fdb.png]: /images/20221020/d88525639d7b471fb2198a0af13300aa.png
[fb7b4c1ec703522c511796a068ca26d9.png]: /images/20221020/f1c8ac3e1d4e4859a1f374696a09d169.png
[353d77e73f09dfbad29841238a94eefe.png]: /images/20221020/ea34e493d8104773bd1c8e7a3956a176.png