如果足够幸运的话,团队成员互不影响,彼此相安无事,大家各自基于 master 分支的某个 commit 创建自己的分支,平时在分支上独立工作,等到一段时间后再合并 merge 到 master 分支,这样一样 master 作为各个功能的集大成者,最终完成项目.
然而事情总不是一帆风顺的,团队协作时由于意见不同,遇到冲突简直是家常便饭,既然无法回避冲突,当冲突发生时如何应该呢?
背景
基于 master 分支上的某个 commit ,新功能由此继续开发:
新功能分支命名为 feature ,使用git checkout -b <name> 创建分支并切换:
在新功能 feature 分支上开发新功能,并提交:
无论新功能 feature 是否开发完毕,团队的其他成员均有可能处于 master 分支并做相应更改:
其他成员对新功能有着自己的看法,于是也提交了版本,由于我们之前提交的是 git commit c2,而此时master 分支提交的是git commit c3,显然我们两个人的意见不一致!
正在此时,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 图形化展示提交历史:
最后,删除新功能分支 feature ,不用的分支及时清理干净,需要时再创建分支.
小结
- 无法杜绝冲突的发生,代码上的冲突本质上是人为因素造成的冲突.
- 解决冲突需要有关双方协商解决,不可能独自解决冲突,除非你抛弃自我,完全以对方为准.
- 使用 git log --graph 命令可以图表化查看提交历史,抑或 git log --pretty=oneline --graph
