This guide demonstrates how to resolve some common conflicts via the command line. You&will&need
a text editor to resolve some of the conflicts.
an edit collision
This is the most common type of conflict. It happens when two branches have changed the same part of the same file, and then those branches are merged together. For example, if you make a change on a particular line in a file, and your colleague working in
a repository makes a change on the exact same line, a merge conflict occurs. Git has trouble understanding which change should be used, so it asks you to help out.
When this sort of conflict occurs, Git writes a special block into the file that contains the contents of both versions where the conflict occurred. To complete this type of merge, use your text editor to resolve the conflict, then add the file and commit it
to complete the merge.
For this example, suppose you're working in&branch-a, and have made some changes to a file calledplanets.md.
Meanwhile, your friend on the other side of the world has made a different change to the same line. If you try to merge your friend's branch into yours, there will be a merge conflict. Runninggit status&tells you about the conflict:
git status
# # On branch branch-b
# # You have unmerged paths.
(fix conflicts and run &git commit&)
# # Unmerged paths:
(use &git add ...& to mark resolution)
# # both modified:
planets.md
# no changes added to commit (use &git add& and/or &git commit -a&)
Both of you have modified&planets.md. When you open the file in your
text editor, you'll see both changes:
the number of planets are
&&&&&&& HEAD
&&&&&&& branch-a
In&branch-a, you wrote the word &nine,& but your friend wrote &eight.& Git automatically adds&conflict
markers&to the affected areas. A conflict-marked area begins with&&&&&&&&&and ends with&&&&&&&&. These are also known as the conflict markers. The two conflicting blocks themselves are divided by a=======.
You have several options here. You can either keep your changes, take your friend's changes, or make a brand new change. Whatever you do, you need to make sure to resolve the conflict such that the file makes sense, and everyone is happy.
In this case, you'll put in a whole new version of the line that reflects what happened. The goal is to get the file to look exactly how you want it. You'll delete the conflict markers, and just type out a new change:
the number of planets are
nine, or eight, depending on who you ask.
That's it! You can now&git add&this file, commit the change with a new commit message, and be on your way.
a removed file conflict
Removed file conflicts occur when one person edits a file, and another person deletes that file in their branch. Git does not know if you want to keep the file with the new edits, or delete the file and forget about those edits. This example will show how to
resolve this both ways.
the edited file
First, you'll resolve the conflict by keeping the new changes. Suppose that you added a line to yourREADME.md&in&branch-b,
but someone else has deleted the file entirely in&branch-c. Git declares the following conflict:
# CONFLICT (modify/delete): README.md deleted in HEAD and modified in branch-b. Version branch-b of README.md left in tree.
# Au fix conflicts and then commit the result.
git status
# # On branch branch-c
# # You have unmerged paths.
(fix conflicts and run &git commit&)
# # Unmerged paths:
(use &git add/rm ...& as appropriate to mark resolution)
# # deleted by us:
# no changes added to commit (use &git add& and/or &git commit -a&)
You can resolve this by adding the file back, and committing it once more:
git add README.md
git commit
# [branch-c 9bc3b01] Merge branch 'branch-b' into branch-c
git show | head
# commit 9bc3b9d076a12f554
# Merge: 4c80a63 7e8b679
# Author: tekkub
Sat Jun 1 18:39:40
Merge branch 'branch-b' into branch-c
Conflicts:
by removing the file
Now, you'll resolve that conflict the opposite way: by leaving the file deleted. Again, with a merge conflict, Git declares:
# CONFLICT (modify/delete): README.md deleted in HEAD and modified in branch-c. Version branch-c of README.md left in tree.
# Au fix conflicts and then commit the result.
git status
# # On branch branch-d
# # You have unmerged paths.
(fix conflicts and run &git commit&)
# # Unmerged paths:
(use &git add/rm ...& as appropriate to mark resolution)
deleted by us:
# no changes added to commit (use &git add& and/or &git commit -a&)
Now, you want to remove the file, so do that with the&git rm&command:
git rm README.md
# README.md: needs merge
# rm 'README.md'
Looks good, so commit it with the default message:
git commit
# [branch-d 6f89e49] Merge branch 'branch-c' into branch-d
git show | head
# commit 6f89e4b1cb041b3999e
# Merge: 211261b fcc1093
# Author: tekkub
Sat Jun 1 18:43:01
Merge branch 'branch-c' into branch-d
Conflicts:
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：46144次
排名：千里之外
转载：144篇
(3)(4)(7)(2)(6)(3)(3)(11)(21)(14)(11)(13)(5)(20)(23)新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
大富大贵, 积分 18267, 距离下一级还需 1733 积分
论坛徽章:11
merge 两个branch 时：比如 r1, r2 两者都有一个bianry
git merge r2
Auto-merging bin/libaudio.a
CONFLICT (content): Merge conflict in bin/libaudio.a
Au fix conflicts and then commit the result.
zhaoyulong@macos:audio/audio_prj$ git st
# On branch master
# Unmerged paths:
#& &(use &git add/rm &file&...& as appropriate to mark resolution)
#& & & & both modified:& && &bin/libaudio.a
# Untracked files:
提示说 git add/rm &file&...； 搞不明白咋处理； 不知道 libaudio.a 处于什么状态， 是 r1 的呢 还是 r2的， 或者 &&&&&xxx ===== yyy 这类的冲突格式呢？
首先vi 打开搜索 === 没有找到， 然后与 r1 原来的 libaudio.a 比较， 发现仍然是 r1 相同的版本； 那么， 就开始琢磨怎么办了， 很显然, git add 是接收当前的 libaudio.a 也就是 r1 版的， 但我想要 r2 版的， 既然 git add 肯定不行， 我就 git rm 吧。。。。。。结果将 libaudio 给删除了。。。。。。。
于是我的 merge 后的缺少了这个文件。。。。。然后想再 merge 告诉你没什么可做的。。。。。。拜托， 好歹一个存在 libaudio.a 另一个缺少这个文件好不。。。。。。。
我现在除了在手工拷贝之外，然后 add 外， 每办法了
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp
丰衣足食, 积分 908, 距离下一级还需 92 积分
论坛徽章:2
是否两个branch里都把bin/libaudio.a加入git repositiory 里，或者说已经tracked。
大富大贵, 积分 18267, 距离下一级还需 1733 积分
论坛徽章:11
peijue 发表于
是否两个branch里都把bin/libaudio.a加入git repositiory 里，或者说已经tracked。
是的， 但现在的问题是 merge branch 的时候， c 文件还能创建 diff 格式的conflict 文件， 直接编辑该文件然后 git add 即可； 二进制文件它压根不给你合并， 仍然是旧的， 你 add 吧， 二进制文件没更新， 不add更不靠普， 直接将该文件 untrack了；
现在只能是先 checkout 分支1， 将 binary 文件重新copy 一份； 然后 checkout 分支2， 然后 git merge 分支1， 等它报错， 将事先拷贝好的binary 文件替换相应的binary, 然后再
简直恶心死
巨富豪门, 积分 29571, 距离下一级还需 10429 积分
论坛徽章:4
你可以在冲突的时候吧你要的版本checkout出来啊，比如你要r1的：
git co --ours libaudio.a
或者要r2的：
git co --theirs libaudio.a
或者直接从branch checkout一个出来：
git co r2 libaudio.a
然后再add嘛……
大富大贵, 积分 18267, 距离下一级还需 1733 积分
论坛徽章:11
对git生， 我试试
丰衣足食, 积分 908, 距离下一级还需 92 积分
论坛徽章:2
4楼正解。 不过两个做merge的branch不应该差距太大。 要是conflict太多的话，还不如bcompare来的省事
北京皓辰网域网络信息技术有限公司. 版权所有 京ICP证:060528号 北京市公安局海淀分局网监中心备案编号：
广播电视节目制作经营许可证(京) 字第1234号
中国互联网协会会员&&联系我们：
感谢所有关心和支持过ChinaUnix的朋友们
转载本站内容请注明原作者名及出处您所在的位置： &
Git历险记(5)：Git里的分支与合并(2)
Git历险记(5)：Git里的分支与合并(2)
本文是《Git历险记》系列的第五篇，译者刘辉通过翻译《Git Community Book》为我们具体讲解Git里的分支与合并以及如何处理冲突的方法。如果你对Git还不了解，可以参看《Git历险记(1)：初识版本控制系统Git》。以下是正文。
如何处理冲突(conflict)
前面说了分支的一些事情，还简单地合并了一个分支。但是平时多人协作的工作过程中，几乎没有不碰到冲突(conflict)的情况，下面的示例就是剖析一下冲突成因及背后的故事：
还是老规矩，新建一个空的Git仓库作试验：
$rm -rf test_merge_proj
$mkdir test_merge_proj
$cd test_merge_proj
Initialized empty Git repository in /home/test/test_merge_proj/.git/
在主分支里建一个&readme.txt&的文件，并且提交本地仓库的主分支里(master):
$echo &hello, world& & readme.txt
$git add readme.txt
$git status
# On branch master
# Initial commit
# Changes to be committed:
# (use &git rm --cached ...& to unstage)
# new file: readme.txt
git commit -m &project init&
[master (root-commit) d58353e] project init 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 readme.txt
当看当前版本所包含的blob:
$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p
100644 blob 4b5fa642ef09f17d readme.txt
虽然前面把&readme.txt&这个文件提交了，但是暂存区里还是会暂存一下，直到下次&git add&时把它冲掉：
$git ls-files --stage
b5fa642ef09f17d 0 readme.txt
然后再创建测试分支(test branch)，并且切换到测试分支下工作：
$git branch test
$git checkout test
Switched to branch 'test'
再在测试分支里改写&readme.txt&的内容，并且提交到本地仓库中：
$echo &hello, mundo& & readme.txt
$git add readme.txt
$git commit -m &test branch modified&
[test 7459649] test branch modified 1 files changed, 1 insertions(+), 1 deletions(-)
现在看一下当前分支里的&readme.txt&的&SHA1哈希串值&确实不同了：
$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p
100644 blob 034a81de5dfb592a2f3f50f66f474dd readme.txt
暂存区里的东东也不一样了：
$git ls-files --stage
a81de5dfb592a2f3f50f66f474dd 0 readme.txt
现在我们切换到主分支(master)下工作，再在&readme.txt&上作一些修改，并把它提交到本地的仓库里面：
$git checkout master
Switched to branch 'master'
$git add readme.txt
echo &hola,world& & readme.txt
$git add readme.txt
$git commit -m &master branch modified&
[master 269ef45] master branch modified 1 files changed, 1 insertions(+), 1 deletions(-)
现在再来看一下当前分支里的&readme.txt&的&SHA1哈希串值&：
$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p
100644 blob aac629fbd9c662e6548fdc readme.txt
暂存区里的内容也改变了：
$git ls-files --stage
100644 aac629fbd9c662e6548fdc 0 readme.txt
主分支(master) 和测试分支(test)里的内容已经各自改变了(diverged)，我们现在用&git
merge&命令来把两个分支合一下看看：
$git merge test
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Au fix conflicts and then commit the result.
合并命令的执行结果不是&Fast-foward&，而是&CONFLICT&。是的，两个分支的内容有差异，致使它们不能自动合并(Auto-merging)。
还是先看一下工作目录的状态：
$git status
# On branch master
# Unmerged paths:
# (use &git add/rm ...& as appropriate to mark resolution)
# both modified: readme.txt
no changes added to commit (use &git add& and/or &git commit -a&)
现在Git提示当前有一个文件&readme.txt&没有被合并，原因是&both modified&。
再看一下暂存区里的内容：
$git ls-files --stage
b5fa642ef09f17d 1 readme.txt
100644 aac629fbd9c662e6548fdc 2 readme.txt
a81de5dfb592a2f3f50f66f474dd 3 readme.txt
看一下里面的每个blob对象的内容：
$git cat-file -p 4b5fa6
hello, world
$git cat-file -p aac629
hola,world
$git cat-file -p 034a81
hello, mundo
我们不难发现，&aac629&是当前主分支的内容，&034a81&是测试分支里的内容，而&4b5fa6&是它们共同父对象(Parent)里的内容。因为在合并过程中出现了错误，所以Git把它们三个放到了暂存区了。
现在我们再来看一下工作目录里的&readme.txt&文件的内容：
$cat readme.txt
&&&&&&& HEAD
hola,world
hello, mundo
&&&&&&& test
HEAD&下面就是当前版本里的内容;而&=======&之下，&&&&&&&&
test&之上则表示测试分支里与之对应的有冲突的容。修复冲突时我们要做的，一般就是把& &&&&&&&
HEAD&，&=======&和& &&&&&&& test&这些东东先去掉，然后把代码改成我们想要的内容。
假设我们用编辑器把&readme.txt&改成了下面的内容：
$cat readme.txt
hola, mundo
然再把改好的&readme.txt&用&git add&添加到暂存区中，最后再用&git
commit&提交到本地仓库中，这个冲突(conflict)就算解决了：
$git add readme.txt
$git commit -m &fix conflict&
[master ebe2f18] fix conflict
这里看起来比较怪异的地方是Git解决了冲突的办法：怎么用&git add&添加到暂存区去，&git
add&不是用来未暂存文件的吧，怎么又来解决冲突了。不过我想如果你仔细读过上一篇文章的话就不难理解，因为Git是一个&snapshot&存储系统，所有新增加的内容都是直接存储的，而不是和老版本作一个比较后存储新旧版本间的差异。
Git里面合并两个版本之间的同一文件，如果两者间内容相同则不作处理，两者间内容不同但是可以合并则产生一个新的blob对象，两者间内容不同但是合并时产生了冲突，那么我们解决了冲突后要把文件&git
add&到暂存区中再&git commit&提交到本地仓库即可，这就和前面一样产生一个新的blob对象。
假设我们对合并的结果不满意，可以用下面的命令来撤消前面的合并：
$git reset --hard HEAD^
HEAD is now at 050d890 master branch modified
从git reset(2)命令的输出结果可以看到，主分支已经回到了合并前的状态了。
我们再用下面的命令看一下&readme.txt&文件，确认一下文件改回来没有：
$cat readme.txt
hola,world
由于Git采用了&SHA1哈希串值内容寻值&、&快照存储(snapshot)&等方法,
Git中创建分支代价是很小的速度很快;也这是因为如此，它处理合并冲突的方法与众不同。
在这里我想起了&C语言就是汇编(计算机硬件)的一个马甲&这句话，其实Git也就是底层文件系统的一个马甲，只不过它带了版本控制功能，而且更加高效。Git里有些命令可能不是很好理解(如解决合并冲突用git
add)，但是对于系统层而言，它是最高效的，就像是C语言的数组下标从0开始一样。
原文连接：
【编辑推荐】
【责任编辑： TEL：（010）】
内容导航&第 1 页： &第 2 页：
关于&&&&的更多文章
历经一年的开发与测试，Linux Deepin 12.12 正式版本终于出炉。
开源技术的不断发展为IT人员的工作提供了便利，在开源
本专题总结了Apache软件基金会（简称ASF）中的十个命
日，Velocity China 2013 Web 性能与运维
《程序员密码学》涉及密码学的各个研究方向，分组密码、散列函数、公钥密码以及相关的攻击，同时也讲解了密码学算法实现上常用的
51CTO旗下网站下次自动登录
现在的位置:
& 综合 & 正文
解決git merge conflict
由于在local做了改动，在执行git merge upstream/master出现conflict。现总结解决方法：
首先参考：
/2013/03/vimdiffgit-merge-conflict_28.html
使用vimdiff來解決git merge conflict 最近同時家裡用筆電跟辦公室用桌電，在兩個地方使用git/github來管理程式作業，這兩個東西加起來根本神物，本來要用隨身碟同步的東西，現在可以用git直接完成。
關於git的基本介紹我就不解釋了，網路上隨便一找就有一堆資源，例如右邊友站連結，作者比我強30dB的JJL blog，裡面有git的基本使用方式；作者當初則是看參考資料一的progit來學git。
作者遇到的問題是：有時候檔案在github上的檔案已經更新，本地的檔案也有修改過，這時候若想要git pull的話會產生conflict，這時候就需要把本地的檔案刪掉重新clone使用merge來解決衝突，偏偏作者手殘常常把檔案merge成連&&&, &&&都保留下來的檔案，相當麻煩；這次好好的研究一下怎麼用vimdiff作為merge的工具，在這裡記錄一下。
首先呢，我們可以先設定vimdiff為git default的mergetool
git config --global merge.tool vimdiff
為什麼？沒辦法，用vim就是潮(誤)
那麼來merge吧，輸入
git mergetool
這時候應該會打開vimdiff，然後產生左上角、中上、右上、下四個視窗，說明如下：
左上：local：顯示本機的檔案內容，現在這個git資料夾的版本
右上：remote：顯示遠端，你要merge的分枝
中上：base：顯示上面兩個分枝的基部的內容
下：merged：顯示merge的內容，也是是包含了那堆&&&&&&, &&&&&& 的版本，我們的目標就是把下面這個修到我們希望的版本。
到了這裡就開始解衝突啦，事實上不單是git，平時如果有兩個很像的檔案要合併，也可以用vimdiff開啟來解，使用的指令是這些：
[c：跳到上一個衝突點
]c：跳到下一個衝突點
:diffget，從某個視窗取得內容
:diffput，把內容丟去某個視窗
可以用:help do, :help dp查怎麼用，不過兩個指令的基本格式是：
:[range]dp|do bufspec
如果是雙方比較，那就沒什麼好說的，do/dp的對象就是另一個視窗的內容，這時候只要在衝突點在一般模式下用dp,do即可。但如果是現在這種3方比較時，就沒辦法這麼方便，而是要直接輸入:diffget/put bufspec來操作(可以打diffg, diffpu來少打幾個字，不過有差嗎=w=)
以上圖為例，我們游標停在下面的衝突點上，要使用remote的視窗內容。
這裡bufspec(用哪個視窗的內容)有兩種指定方式：
1. 先用:buffes，確認remote那個視窗編號，我是4號，因此用 :diffget 4
2. 用關鍵字，這個超強，用 :diffget REMOTE (因為git自動命名暫時檔名為 XXXX.REMOTE.yyy, XXXX.BASE.yyy, XXXX.LOCAL.yyy)即可。
如此就會套用remote的內容了，經過幾次套用之後，畫面可能會變得有點亂，這時候可以用 :diffupdate來重新產生diff的格式。
用上面的步驟，就可以快速的完成解衝突的工作，做完之後，在下面的合併檔存個檔離開吧。
其次参考：
/sinojelly/archive//2130172.html
很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。
而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。
git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。
冲突的类型
git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。
比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。
又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。
这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。
两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种，后面的解决办法也主要针对这种冲突。
文件名修改造成的冲突，称为树冲突。
比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。
$ git status
added by us:
both deleted:
origin-name.c
added by them:
如果最终确定用b.c，那么解决办法如下：
git rm a.c
git rm origin-name.c
git add b.c
git commit
执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。
树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。
最后执行git commit提交即可。
内容冲突的解决办法
一般来讲，出现冲突时都会有“CONFLICT”字样：
$ git pull
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Au fix conflicts and then commit the result.
但是，也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：
error: project mini/sample
注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。
这个时候，需要进入报错的项目（git库）目录，然后执行git rebase解决：
git rebase remote-branch-name
冲突解决的一般过程
merge/patch的冲突解决
先编辑冲突，然后git commit提交。
注：对于git来讲，编辑冲突跟平时的修改没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。
rebase的冲突解决
rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。
解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也就是把修改内容加入缓存）：
git add -u
注：-u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。
然后执行下面命令继续rebase：
git rebase --continue
有冲突继续解决，重复这这些步骤，直到rebase完成。
如果中间遇到某个补丁不需要应用，可以用下面命令忽略：
git rebase --skip
如果想回到rebase执行之前的状态，可以执行：
git rebase --abort
注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。
编辑冲突的方法
直接编辑冲突文件
冲突产生后，文件系统中冲突了的文件（这里是test.txt）里面的内容会显示为类似下面这样：
a123&&&&&&& HEAD
b789=======
b&&&&&&& 1e684d3a6c02d4d0dcc
其中：冲突标记&&&&&&& （7个&）与=======之间的内容是我的修改，=======与&&&&&&&之间的内容是别人的修改。
此时，还没有任何其它垃圾文件产生。
最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。
利用图形界面工具解决冲突
如果要解决的冲突很多，且比较复杂，图形界面的冲突解决工具就显得很重要了。
执行git mergetool用预先配置的Beyond Compare解决冲突：
$ git mergetool
Merging:test.txt
Normal merge conflict for 'test.txt':
{local}: modified
{remote}: modified
上面三个窗口依次是“LOCAL”、“BASE”、“REMOTE”，它们只是提供解决冲突需要的信息，是无法编辑的。
下面一个窗口是合并后的结果，可以手动修改，也可以点击相应颜色的箭头选择“LOCAL”或者“REMOTE”。
在Beyond Compare中修改冲突保存后，冲突文件（test.txt）中的冲突标记就没有了，成了修改后的内容，一个文件的冲突编辑就完成了。
启动Beyond Compare之后，会自动生成几个包含大写字母名称、数字的辅助文件：
关闭Beyond Compare时，这几个辅助文件都会自动删除，但同时会生成一个test.txt.orig的文件，内容是解决冲突前的冲突现场。
默认该.orig文件可能不会自动删除，需要手动删掉。
自己总结：
git config --global merge.tool vimdiff
2.git mergetool(回车)
3.:buffes确认编号
4.：diffget
4选择remote为当前版本（或使用":,4"）
5.":xa"退出
6. git add .
7. git commit -m ""
8. 删除.orig文件文件
&&&&推荐文章:
【上篇】【下篇】