git rebase和merge --ff-only结合起来太好用啦！

一、简介

• 什么是 git rebase

  rebase是一种合并分支的方式，它可以将一个分支上的提交应用到另一个分支上，而不会产生合并提交。通过使用rebase，我们可以保持提交历史的线性顺序，使得分支的合并更加干净和整洁。

二、使用场景

• git rebase可以做什么

  简单来说，就是让提交历史更简洁，例如：

  1. 将当前分支（dev）的更改重新应用到另一个分支上（feature）。
  2. 将公共分支（master）新的更新集成到自己的分支中，同时保持自己的提交在最新的基底之上

三、使用优势

• git rebase 与 git merge的区别

  rebase和merge都是用来合并分支的，但是合并后的效果却是不一样的，根据以下场景，请看2个示例：

首先基于master分支创建dev分支
然后dev分支先进行开发，并提交
接着master也进行开发（忽略为什么会直接在master开发，只是举例），并提交
然后完成dev向master的合并

以下是使用merge的方式 以下是使用rebase的方式

四、注意事项

• rebase注意事项

  通过上面两幅图，我们可以观察到，merge会产生一个合并的记录：Merge branch 'dev'，而rebase的提交历史是线性的。

  但是有细心的小伙伴会发现dev是先提交的，但是在这里dev的提交记录在master之后，这样影响了提交的顺序。又有小伙伴想，你先在master上执行rebase不就得了？这样顺序不就对了？

  没毛病，这样确实会把顺序调整正确，但是实际开发中，这样操作会把提交历史搞乱。

  为什么会搞乱，首先，先在master上执行rebase，相当于直接把master的根基变了，那么其他基于master的分支再合并代码的时候，必然会冲突，我们想一个场景，我们在master提交之后再基于此新建一个bugfix分支，那么bugfix的提交历史：

  • master后续提交 bramble 3 minutes ago
  • init bramble 2024/2/1 17:03

  如果是现在在master分支执行rebase，那么master的提交历史：

  • master后续提交 bramble A minute ago
  • dev初次提交 bramble A minute ago
  • init bramble 2024/2/1 17:03

  可以看到，master的提交历史虽然是按时间排序了，但是master的根基却已经变了，原来第二次提交是：master后续提交，现在变成了：dev初次提交，此时如果把bugfix的代码合并过来必然会冲突。 而以上之所以冲突就是因为在master上执行了变基，所以要注意的就是不要在公共的分支上使用rebase，切记切记！

五、配合--ff-only使用非常好

上面提到，不要在公共的分支上使用rebase，那么公共分支的提交历史就只能还是乱七八糟的？每次合并其他分支的代码都多一个Merge的信息？

当然不是，我了解到merge有一个配置，整个命令是这样：git merge --ff-only dev,这个命令的含义是：尝试将 dev 分支合并到当前分支，但仅当可以进行快进（fast-forward）合并时才执行。那么什么是fast-forward呢？比如当前所在分支是master，另外的分支dev中完全包含master的内容，另外多出来的内容就可以使用这个命令合并过来，通过此命令合并后，并不会产生merge信息。比如:

以下是master的提交历史

• master后续提交 bramble 45 minutes ago
• dev初次提交 bramble 45 minutes ago
• init bramble 2024/2/1 17:03

以下是dev的提交历史

• dev后续提交 bramble Moments ago
• master后续提交 bramble 46 minutes ago
• dev初次提交 bramble 47 minutes ago
• init bramble 2024/2/1 17:03

可以看到dev的提交历史完全包含master的提交历史，另外多了一条：dev后续提交，所以就可以进行fast-forward，那么此时把dev分支合并到release，直接执行命令git merge --ff-only dev即可。 具体命令如下：

PS D:\github\git-learn>git merge --ff-only dev
Updating 6c80b44..fec9da6
Fast-forward
 two.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
PS D:\github\git-learn> 

这样合并之后，master的提交历史仍然是线性的。

六、总结

上面做了一些相关场景的演示，可能有不全面的地方，请大家积极提出，我会尽量修改。对于之前没有使用过rebase的，可以进行参考，其实简单来说，就是在自己个人的分支上执行rebase，把公共分支的代码线性的合并进来，然后公共分支合并自己分支的时候再使用--ff-only达到线性历史。使用起来还是比较方便的。期待大家都尝试一下，另外切记不要在公共分支使用哦！

七、感谢

最后，感谢你的耐心阅读，如果我的分享对你有所启发或帮助，就给个赞呗，很开心能帮到别人。♥♥♥♥