git rebase和merge处理冲突
·约 959 字·3 分钟
AI摘要: 当远程仓库有新的修改而本地仓库未同步时，继续在本地进行修改会导致冲突。Git提供了两种处理方式：Merge和Rebase。Merge会生成一个新的提交来汇总C和D的提交，但可能产生冲突，需要手动解决。Rebase则按照线性提交处理，历史记录更整洁。使用建议上，个人分支上使用Rebase较为安全，公共分支上要谨慎。
当我们的远程仓库有新的修改，但是本地仓库并没有同步，这个时候继续在本地仓库上修改完是无法提交到远程仓库，因为发生了冲突。
具体而言，远程仓库的提交历史A -> B -> C, 本地仓库的提交历史A->B->D , 远程仓库的C修改未同步到本地，本地的D修改也无法提交到远程。
(其实就是自己在Github网站上修改了README文件，本地仓库忘了同步回来就开始写代码，最后提交报错)
这个时候有两种处理方式，并会在git提交上以两种不同的形式展示。
Merge
Merge合并会生成一个新的提交M, 这样来汇总C提交和D提交，不过C提交和D提交很可能是有冲突的，这个时候就需要手动处理冲突部分。
实现步骤
git config pull.rebase false
git pull
git status
<<<<<<< HEAD
你的修改
=======
远程的修改
>>>>>>> branch-name
git add .
git commit -m "解决合并冲突"
那么在git历史图中将会以分叉图的形式展示：
A -> B -> C -> M (M是一个合并提交)
\-> D -> E/
这种方式保留完整的历史记录，但是分支历史会显得比较杂乱
Rebase
Rebase是按照线性提交处理，历史记录非常漂亮。
实现步骤：
git config pull.rebase true
git pull
最终git历史的形式为:
A -> B -> C -> D' (线性历史)
使用建议
在个人分支上使用 rebase 很安全
在公共分支上要谨慎使用 rebase
如果不确定，可以先使用默认的 merge 策略
需要注意的是，如果已经将代码推送到远程，使用 rebase 后需要强制推送（git push -f），这可能会影响其他开发者，所以要格外小心。