git rebase使用场景

• TOC
  {:toc}

场景1，多用户对同一远程仓库进行提交

A，B同时从仓库pull下来代码，此时两人代码是一样的。

​ 首先是A，进行了修改

//修改文件a.txt
git add a.txt
git commit -m "修复bug1"

​ 此时A的log是：


​ 然后是B进行了修改,并推送到远程分支

//修改文件a.txt
git add a.txt
git commit -m "修复bug2"

//修改文件a.txt
git add a.txt
git commit -m "修复bug3"

git push origin master

​ 此时B的log是下图两个提交，由于B已经push到远程分支了，远程分支的提交记录是和B一样的。


​ 然后A想push时，会发现报错了，自己需要先pull合并，再push，于是A

git pull origin master
//解决冲突
git add a.txt
git commit -m "解决冲突"

​ 此时A的log变成了这样


​ 这是因为需要把B提交的东西合并过来，所以产生了一个用于解决合并冲突的提交。强迫症觉得很不舒服。

但是如果B提交后，A再拉取代码，在B提交基础上进行开发就不会产生分叉。这里可以使用rebase命令进行变基,将基变成修复bug3的那次提交。

​ A想到使用变基方法，于是

git rebase origin/master
//解决冲突
git add a.txt
git rebase --continue

​ 此时提交日志变成这样


​ 通过对比上面的提交日志，可以看到修复bug1变成基于修复bug3那次提交，而不是原来那个提交了。这样就解决了分叉。

rebase 后面跟的分支名，意思是将当前分支的基线，变成指定的分支。

场景2，多分支之间的冲突

A的本地初始版本是这样的


A想创建一个dev分支进行开发，于是

git checkout -b dev

git add a.txt
git commit -m "正常开发1"

git add a.txt
git commit -m "正常开发1"

A进行两次正常提交后log是这样的，dev分支超过master分支两次提交


这是遇到一个紧急bug需要修复，于是A从master分支开启一个分支进行紧急修复,并合并到主线。

git checkout master
//修复
git add a.txt
git commit -m "进行修复紧急"

此时master分支的log是这样的


A继续回到dev分支开发，开发完成后想要将dev分支合并到master，因为dev分支的基线和当前master的是不一致的，就会产生分叉。


所以这里不要直接将dev分支合并到master，要先对dev分支进行rebase，将基线变成当前master，然后再合并。

撤销上面的合并操作，先进行下面操作

git checkout dev
git rebase master
//解决冲突
git add a.txt
git rebase --continue

此时dev分支的log是这样的，发现进行紧急修复的提交已经过来了,且成为了dev分支的基线。


这是再进行合并，就可以无冲突合并了。

git checkout master
git merge dev


场景3，合并多次提交记录为一次

​ 解决一个问题可能进行了多次提交，但每次提交更改的都比较少，或者是经过反复修改，想在想要将多次提交合并成一个可以这么做。

起初日志是这样的:


然后问题解决了提交记录就成了这样，中间两次提交都是没有意义的。


下面将三次提交合并成一次

git rebase -i HEAD~3

弹出编辑框如下，可以仔细阅读下面的命令。


我们将后两个提交的命令改为squash,意思就是合并到前一个提交上去，然后保存


保存后还有一次重写提交日志的机会。保存后的记录成了这样，三次提交汇总成了一次。


总结

​ 以上就是rebase的基本用法，用好rebase可以让我么的git记录更清晰。