rebase会把当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像从公共分支又重新拉出来这个分支一样。
举例：
如果从 master 拉个feature分支出来,然后提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你 rebase master 的话，就会把你当前的几个 commit，放到那个人 commit 的后面。
主分支产生了新的提交
rebase变基操作
merge合并操作
采用merge和rebase后，git log的区别，merge命令不会保留merge的分支的commit：
面试解读
merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容
merge 的提交历史忠实地记录了实际发生过什么，关注点在真实的提交历史上面
rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面
rebase 的提交历史反映了项目过程中发生了什么，关注点在开发过程上面
merge 与 rebase 都是非常强大的分支整合命令，没有优劣之分，使用哪一个应由项目和团队的开发需求决定
merge做的操作是两次提交合并，并合成一次新的提交，弊端通过查看记录发现已经不是一个线性的历史记录了，有些人就喜欢看线性的结构，如果我们想让他变成一种线性结果，就需要要用到rebase这个操作，rebase，中文意思变基的意思，他更相当于是操作系统当中的剪切命令，把然后放置到某次提交的后边，通常的使用方式是，切换到被合并的分支上然后再使用命令如下
git rebase master
rebase使用的黄金法则
- 永远不要在主分支上使用git rebase
为什么永远不要在主分支上使用git rebase
- 如果在main上面使用rebase，会造成大量的提交历史在main分支中不同；
- 而多人开发时，其他人依然在原来的main中，对于提交历史来说会有很大的变化；
