冲突合并

如果足够幸运的话,团队成员互不影响,彼此相安无事,大家各自基于 master 分支的某个 commit 创建自己的分支,平时在分支上独立工作,等到一段时间后再合并 mergemaster 分支,这样一样 master 作为各个功能的集大成者,最终完成项目.

然而事情总不是一帆风顺的,团队协作时由于意见不同,遇到冲突简直是家常便饭,既然无法回避冲突,当冲突发生时如何应该呢?

背景

基于 master 分支上的某个 commit ,新功能由此继续开发:

echo "git commit c1" >> test.txt
$ git add test.txt
$ git commit -m "git commit c1"
git-commit-c1.png

新功能分支命名为 feature ,使用git checkout -b <name> 创建分支并切换:

git-checkout-feature.png

在新功能 feature 分支上开发新功能,并提交:

git-commit-c2.png

无论新功能 feature 是否开发完毕,团队的其他成员均有可能处于 master 分支并做相应更改:

git-checkout-master-c1.png

其他成员对新功能有着自己的看法,于是也提交了版本,由于我们之前提交的是 git commit c2,而此时master 分支提交的是git commit c3,显然我们两个人的意见不一致!

git-commit-c3.png

正在此时,feature 分支的新功能已开发完毕并主动切换回 master 分支,准备合并 feature 分支.

由于项目成员沟通不畅或者意见不一致,导致了代码冲突,git 作为版本控制系统,自然无法解决这类问题,总不能擅自做主抛弃后来的更改吧或者抛弃分支更改?所以 git 只负责抛出问题,等待我们程序员去解决问题.

既然是人的问题,那我们看一下我们到底是哪里不一致,为什么会产生冲突?

和我们预期一样,test.txt 文件产生了冲突,当前 HEAD 指向的提交即 master 分支是 git commit c3 ,而 feature 分支是 git commit c2,对于同一个文件的同一行内容发生不同的更改,git 不知道也不应该知道如何处理.

git<<<<<<< 标记一个分支冲突开始,======= 标记分支分割线,>>>>>>> 标记另一个分支结束.

经过冲突双方的讨论后,彼此间达成妥协,决定修改成git commit c2 and c3 ,修改后继续提交:

冲突已经解决,现在回顾一下提交历史,使用git log --graph 图形化展示提交历史:

git-merge-with-conflict.png

最后,删除新功能分支 feature ,不用的分支及时清理干净,需要时再创建分支.

小结

  • 无法杜绝冲突的发生,代码上的冲突本质上是人为因素造成的冲突.

  • 解决冲突需要有关双方协商解决,不可能独自解决冲突,除非你抛弃自我,完全以对方为准.

  • 使用 git log --graph 命令可以图表化查看提交历史,抑或 git log --pretty=oneline --graph

最后更新于

这有帮助吗?