1.合并commit

之前有一个后端同学跟我说了这个,他感觉一个分支上好多commit会感觉很难看,所以每次在自己的分支开发完毕之后,他会通过rebase把自己的分支内容进行合并成一个commit,但是我感觉这个可能不太好,毕竟看不到我每次提交的记录,现在整合成一个commit会会很难回溯之前的思路提交,好处是code review的时候更方便检查这次的更改内容,不过用分支对比不是更好吗?

具体用法

git rebase -i (之前的分支(不包括该分支)  之后的分支]

git rebase -i HEAD~number 前几次的提交

这时候会出来一个编辑内容
rebase1.png
常用的也就squash和fixup,一个是把当前的提交塞入之前的提交中 另外一个也是差不多,但是后面不会有commit 信息记录,算是直接当成修复commit了

2.合并分支

如果用merge去合并你的开发分支到master分支,这时候别人也要merge分支,如果你们的代码在同时开发可能就会有交叉的commit,这样git树看起来就很混乱,然而rebase会始终让你的修改放在一起

说下一个场景

  1. 有一天接到一个需求A,这时候我们从master分支拉取一个featXXX分支开发一个新功能,约定这周四上线
  2. 第二天结果发现线上有个BUG,这时候我们又从master拉取一个分支叫fixXXX,此时呢,修复好了,然后给他合并到了master分支
  3. 终于到周四,我们上线新的需求,这时候我们把代码合并到master之后,会突然发现代码的git图表会分叉,并且会有一个merge的commit

1.png
所以我们先需要在我们的featXXX分支上先rebase一下master,然后再切到master分支让master去合并我们的featXXX分支,这时候就是一条直线
2.png
这样的好处就是git图上不会有那么多分叉commit,导致混乱

Last modification:November 1st, 2021 at 03:28 pm
If you think my article is useful to you, please feel free to appreciate