Git rebase使用

Posted 2023-03-20

参考技术A git rebase能够将分叉的分支重新合并，之前写过一篇文章介绍它的原理，下面主要介绍它的两个使用场景：

多个人在同一个分支上协作时，出现冲突是很正常的，比如现在有一个项目由我和A一同开发。

我在修复了一个bug以后准备提交

现在准备推送到远端

push失败了，说明A在我之前已经提交了，我本地master分支的提交历史已经落后远端了，需要先pull一下，与远端同步后才能push

pull成功，现在使用git log看下一提交历史：

竟然分叉了！由于我本地master的提交历史和远端的master分支的提交历史不一致，所以git为我进行了自动合并，然后生成了一个新的提交历史（ f63ecbf Merge branch 'master' of ）

对于部分强迫症来说这个不能接受的，不想看到分叉。

这个时候用 git rebase 就可以解决

现在再查看一下提交历史：

完美解决，现在再push推送到远端：

再次查看提交历史

现在远端master，远端head，本地master全部统一，问题解决。

直接执行：
git pull --rebase
效果与上面是一致的，也是最近才发现，推荐使用

由于老板突发奇想，要求开发一个新的功能。

先创建一个分支用于开发新功能：

git checkout -b feature

接下来修改newFunc.go，增加新的功能,并且保存提交

vim newFunc.go

git add newFunc.go

git commit -m 'add new func'

现在查看一下提交

现在新功能开发完毕，需要将它合并的主分支中。

首先切换到master分支

git checkout master

直接合并feature分支

git merge feature

竟然失败了，说明我两个分支之前的版本已经不同步了，需要手动合并冲突，再提交：

先查看冲突文件： git status

打开文件，进行修改

原文件：

修改后：

现在通过add添加，然后commit提交

现在在查看一下分支提交历史：

虽然合并成功，但是Master已经保存了合并历史，出现开叉了！对于强迫症患者来说肯定是不能接受的。

现在将版本退回到合并前,也就是回退一个版本

git reset --hard head^

退回去了，现在是位于master分支的 init base 提交这里。

先切换回feature分支：

在feature分支上执行: git rebase master

这句命令的意识是：以master为基础，将feature分支上的修改增加到master分支上，并生成新的版本。

失败了，原因很简单，两个分支修改个同一个文件，产生了冲突。所以先需要解决冲突：

打开冲突的文件，解决冲突

原文件：

修改后：

现在通过add添加

现在是重点，之前的rebase其实只是完成了一半，由于出现冲突而终止，现在冲突解决，可以通过 git rebase —continue 继续完成之前的rebase操作。

rebase完成，再查看一下提交历史：

提交记录已经是一条完美的直线。现在切换到主分支master，将feather分支上的提交合并过来。

git checkout master

git merge feature

再次查看一下提交历史：

问题解决，master上也是一条直线了。

最后收个尾，删除掉feature分支：