比如有两个开发了比较多功能的分支，或者在比较久的一次提交上做了一个hotfix，这个时候如果合并，通过ui查看会有一条额外的很长的线连接过来，不美观，看起来也不方便。

可以用rebase进行变基，强行把两个分支的内容合并到一起。

rebase与merge的区别

merge就是把两个分支，当前的内容，进行比较，如果没有冲突，就把对应的内容做修改，产生一次新的提交。

rebase是把指定的分支作为当前分支的底座，从相同的起点开始（因为大家肯定是从某次提交切分出来的），把当前的提交按照新的基础，再一次提交一遍。这样就会产生一条新的提交线，并且只有这一条。

流程

注意 如果分支太多，或者太杂乱，并且对rebase不熟悉，建议不要rebase，可能会导致代码丢失。

一在开发分支上rebase依赖的主分支

比如有一个dev分支，突然来了一个小任务，切了一个dev_hotfix分支，开发完成后，需要在dev_hotfix上rebase dev分支。

因为rebase后，整个分支的HEAD的哈希值会变掉，就是虽然内容一致，也会更改，这也是与merge不同的地方，merge是增加一个新提交，都是向前进的，而rebase是修改每一次提交，并没有前进。如果在公共分支上rebase，就会导致与远程分支冲突，这时候不管怎么解决都很恶心，如果pull加merge，就会出现相同的提交存在两次，因为git通过哈希值判断，虽然是相同提交，因为rebase做了重新提交，所以哈希值变了，就会认为是不同提交，就存在了两个；如果强制push，那么所有人都会冲突，还会导致远程代码和其他人代码丢失。所以切忌不要在公共分支rebase。

在依赖分之上merge rebase后的分支

上面也说明了，肯定不可能在公共分支上rebase，那么只有merge了。有人会问，merge后不会出现额外多一条线的情况吗，答案是不会的，因为开发分支已经以依赖分支变基了，相当于在依赖分支上做的开发，当merge过来后，就相当于在依赖分支上依次提交了记录，在自己分支上提交记录，怎么会额外多一个提交流程呢。

总的来说，rebase相当于在一个基础上，依次提交当前分支的记录；merge是把两个分支合并