1.合并commit

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

具体用法

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

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

这时候会出来一个编辑内容

常用的也就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

所以我们先需要在我们的featXXX分支上先rebase一下master，（或者git pull master --rebase）然后再切到master分支让master去合并我们的featXXX分支，这时候就是一条直线

这样的好处就是git图上不会有那么多分叉commit，导致混乱