Git作为“现代”开发中不可获取的一部分,平时的最常用的几个命令是 init clone push pull origin。但Git包含的功能却远远不止这些。说起命令,就想起之前面试官提到了rebase,然后就尝试了一下rebase这个命令,最后发现这完全是强迫症的福利。只要平时的开发流里再多几个简单操作,世界就能变得很美好,而且有了IDE的加持,用起来更加简单便捷了。然后,虽然这个前言感觉很唐突,天道好轮回,技术债也是要还的。

合并的策略

合并从场景来说分为两种, 不同分支的合并单个分支的合并

不同分支的合并这个没什么可说的,参照 git merge --no-ff xxx 的命令执行。
而单个分支的合并一般在多人开发同一个分支的时候,如果有人提前提交到了远程仓库,那么其它人再想提交的话,就必须先把远程仓库的修改合并到本地,才能再次提交。

同事们大多数都是commit后发现提交不上去,然后pull一下执行一次同分支合并。这样提交记录里就会华丽丽的看到很多分支自己merge自己的情况了,而这种提交记录是完全没有必要的。(忽略黑黑的打码)

marge 特点:自动创建一个新的commit
如果合并的时候遇到冲突,仅需要修改后重新commit
优点:记录了真实的commit情况,包括每个分支的详情
缺点:因为每次merge会自动产生一个merge commit,所以在使用一些git的GUI tools,特别是commit比较频繁时,看到分支很杂乱。

rebase 特点:会合并之前的commit历史
优点:得到更简洁的项目历史,去掉了merge commit
缺点:如果合并出现代码问题不容易定位,因为re-write了history

单分支 下,建议使用rebase将远程分支更新到本地。 多分支 合并,使用merge策略合并分支。

rebase使用

rebase的其它用法就不再介绍了(其实是暂时用不上,等用上了再说),只说明一下pull的时候的用法。

有人可能会说,那我在commit之前先pull一下,这样不就可以了?

这种方法完全可以,“事前”可以用来规避单分支合并出现无用commit的问题,但是不小心到“事后”了会怎样。

rebase使用起来非常简单,命令行模式下记得在pull的后加 --rebase 参数。常用命令如下:

1
2
3
4
5
6
git pull --rebase     # 以rebase方式拉取代码

# 遇到冲突时
git rebase --continue # 遇到冲突,解决冲突后执行,继续rebase剩余代码
git rebase --skip # 忽略冲突的commit,继续rebase剩余代码
git rebase --abort # 终止rebase,回到rebase执行前状态

GUI以Intellij为例

提交代码前先更新项目,使用rebase方式

遇到冲突时解决冲突,IDE会自动执行 --continue 命令。

与平时使用的merge真的很像。

总结一下

rebase的一些用法:

  1. 合并多个commit为一个完整的commit
  2. 将某一段commit粘贴到另一个分支上

rebase实质是丢弃一些现有的提交,然后相应地新建一些内容一样但实际上不同的提交。

rebase会改写历史记录,永远不要在已经push了的commit上使用。

还是稍微吐槽一下 变基 这个名词吧,感觉很magic⭐

参考文献