如何克服解决Git冲突的恐惧症?(Git基础篇--下)

在上一篇中,介绍了git的初始化配置配置、获取帮助、初始化仓库、跟踪新文件、提交、忽略某些文件,以及分支,具体文章:如何克服解决Git冲突的恐惧症?(Git基础篇–上),本篇将介绍分支合并相关的git mergegit rebase

merge

分支合并的方法一就是git merge,通过图示更容易理解:

执行命令如下:

1
2
3
git merge bugFix
git checkout bugFix
git merge master

执行过程如下:

rebase

分支合并的方法二就是git rebase,通过图示更容易理解:

执行命令如下:

1
2
3
4
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文件内容如下:

1
史培培

bugFix分支的README.md文件内容如下:

1
2
3
4
5
码上论剑

欢迎关注我的公众号

http://hellomypastor.net

在bugFix分支执行如下命令:

1
git pull --rebase

发现冲突:

1
2
3
4
5
6
7
8
9
<<<<<<< HEAD
史培培
=======
码上论剑

欢迎关注我的公众号

http://hellomypastor.net
>>>>>>> init

解决冲突之后,执行:

1
2
git add README.md
git rebase --continue

这样就解决冲突了,是不是很简单?

建议

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

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

坚持原创技术分享,您的支持将鼓励我继续创作!