如何克服解决Git冲突的恐惧症？（Git基础篇--下）

在上一篇中，介绍了git的初始化配置配置、获取帮助、初始化仓库、跟踪新文件、提交、忽略某些文件，以及分支，具体文章：如何克服解决Git冲突的恐惧症？（Git基础篇--上），本篇将介绍分支合并相关的git merge与git rebase。

merge

分支合并的方法一就是git merge，经过图示更容易理解：

执行命令以下：

git merge bugFix
git checkout bugFix
git merge master
复制代码

执行过程以下：

rebase

分支合并的方法二就是git rebase，经过图示更容易理解：

执行命令以下：

git rebase master
//下面两步只是示例，不建议使用
git checkout master
git rebase bugFix
复制代码

执行过程以下：

merge与rebase的对比

Merge好在它是一个安全的操做。现有的分支不会被更改，避免了rebase潜在的缺点，另外一方面，这一样意味着每次合并上游更改时feature分支都会引入一个外来的合并提交。若是master很是活跃的话，这或多或少会污染你的分支历史。虽然高级的git log选项能够减轻这个问题，但对于开发者来讲，仍是会增长理解项目历史的难度。

Rebase最大的好处是你的项目历史会很是整洁。首先，它不像git merge 那样引入没必要要的合并提交。其次，rebase致使最后的项目历史呈现出完美的线性——你能够从项目终点到起点浏览而不须要任何的Fork。这让你更容易使用git log、git bisect和gitk来查看项目历史。

不过，这种简单的提交历史会带来两个后果：安全性和可跟踪性。若是你违反了Rebase黄金法则，重写项目历史可能会给你的协做工做流带来灾难性的影响。此外，rebase不会有合并提交中附带的信息——你看不到feature分支中并入了上游的哪些更改。

rebase黄金法则

当你理解rebase是什么的时候，最重要的就是何时不能用rebase。git rebase的黄金法则即是，毫不要在公共的分支上使用它。

rebase冲突解决

假设有两个分支，master与bugFix：

master分支的README.md文件内容以下：

史培培
复制代码

bugFix分支的README.md文件内容以下：

码上论剑

欢迎关注个人公众号

http://hellomypastor.net
复制代码

在bugFix分支执行以下命令：

git pull --rebase
复制代码

发现冲突：

<<<<<<< HEAD
史培培
=======
码上论剑

欢迎关注个人公众号

http://hellomypastor.net
>>>>>>> init
复制代码

解决冲突以后，执行：

git add README.md
git rebase --continue
复制代码

这样就解决冲突了，是否是很简单？

建议

用pull --rebase，而不用pull（默认merge），这样的话在pull的时候就自行在本地解决两路冲突，而不是merge的时候麻烦的多路merge，这才是git的正确使用方式。

相信你们对git的基础已经基本掌握，不妨在本身的git环境中动手试一试，下篇将讲述《Git分支管理策略》，主要介绍git分支的管理相关内容，敬请期待～

微信公众号： 码上论剑 请关注个人我的技术微信公众号，订阅更多内容