git 解冲突需要注意的问题
“弄清除冲突双向的修改意图,并在解决冲突时,同时处理两边的意图。”
换句话说,不是为了解决冲突而解决冲突,重点搞清楚冲突如何产生,以及如何合并双方的修改。
举例说明
A.txt 文件,
在 master 分支上,有一行文字(代码)是这样:
这是一段在 master 分支上的文字。
Alice 在 dev 分支上,修改了这段文字(代码),修改后如下:
在 dev 上,将 master 的文字修改为这段文字;并添加了其它文字;如果是代码,这些代码相互关联。
Bob 基于 master 分支开发功能,在 f/feature 分支上,也修改了这段代码,如下:
在一个功能分支(f/feature)上修改 master 上的代码;以及与之相关的其它内容。
现在,Bob 需要把 dev 分支的代码合并到 f/feature 分支上,git 命令:(@f/feature) git merge dev
将得到一个冲突。如何解决这个冲突?
解冲突
解冲突推荐使用 GUI 工具,因为直观。这里介绍 tortoisegit 解冲突的操作。
(图1)操作入口:
(图2)冲突列表:
(图3)文件的解冲突页面
对于比较简单的冲突,直接应用某一边的修改,或者做一下简单的编辑(图3中,下面的区域是可以编辑的。)
对于复杂冲突,需要了解两边对同一段代码的修改意图,即对方(Remote)为什么要这样改,要达到什么目的?本方(Local)为什么要这么改,要达到什么目的?
修改比较复杂是,在图3的界面中,可能看不清具体的修改内容,可以在 tortoisegit 中查看两边修改前后的对比。
(图4)查看两边具体的修改。
下面是一张稍显复杂的两边修改的对比图。
(图5)两边修改对比
通过图5 ,可以具体查看两边的修改意图,具体在解冲突是,可能没办法一次处理完。
这时需要先在临时处理冲突(如应用某一边的修改),并记录下另一边的修改(如保留这个窗口,或者截图。)
在 git 的冲突处理完之后(这里其实只是形式上处理完了,实际上丢弃了某一边的修改),再修改代码。
更复杂的情况,可能两边对代码的改动都非常大,需要代码重构才能解决问题。当然,这个情况很少,也应该避免发生。
补充
如图1和图5所示,其中的 Remote 指被合并过来的分支,这里是在 f/feature 上合并 dev , 则 Remote 指 dev 上的修改,Local 指 f/feature 上的修改。
重点
兼顾两边的修改意图,不能因为解冲突,丢失了某一边的修改。
git GUI 与 tortoisegit
其它
这里有个工具可以查看 git 的差异文件 patch file,不过现在用得很少了
megatops/PatchViewer: Single file, browser based patch file viewer.
原文链接: https://blog.jgrass.cc/posts/git-conflict-tortoisegit/
本作品采用 「署名 4.0 国际」 许可协议进行许可,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。