冲突的产生
很多命令都有可能发生冲突的情况, 但是究其根本原因, 冲突其实都是在进行合并操作以及应用补丁的过程当中产生的。
那么, 所谓的重新设置基准这个操作, 就是在应用补丁之前先把基底给换掉, 这整个过程也就是我们说的使用重定基这个手段进行重新定位, 因为步骤复杂, 所以自然也会出现冲突的情况。
因为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
由我们添加, 具体为公元前c。
both deleted: origin-name.c
他们添加了一个名为 a.c 的内容, 并将其加入其中。
在情况变得明确, 确定最终要采用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
自动合并步骤执行失败了, 接下来请去手动解决那些冲突的内容, 然后把最终的结果进行提交操作。
不过话又说回来, 这种情况也是个例外, 关于repo sync这个操作产生的报错信息, 它未必会直接去提示有冲突存在, 而是呈现出下面这副模样。
错误出现了, 这个错误的情况发生在项目目录之中, 具体所指为“mini/sample”。
这里需要注意, 不管有没有发生冲突的情况, 只要你本地的修改不是基于服务器上的最新版本的话, 那么它就会有可能报告这个错误内容, 而且解决这个问题的方法都是一模一样的。
到了这个时候, 需要进入存在报错信息的项目目录之中, 这个目录往往是一个基于 Git 版本的代码库, 接下来则应当执行 git rebase 这一指令来完成解决的操作:
git rebase remote-branch-name
解决冲突的时候, 一般的过程是这样的, 具体来说, 就是关于在合并或者打补丁这个环节里面, 怎么处理那些产生的冲突。
先对冲突的内容进行编辑和调整, 随后再利用git commit指令来进行提交操作。
这里需要特别注意的是在git版本控制系统里面处理合并冲突的情况, 这一操作过程跟平常大家修改代码的行为是没有任何本质区别的, 当你把需要变动的内容调整完毕之后, 接下来的标准步骤仍然是先把这些更改好的数据加入到索引也就是暂存区这个环节中, 接着再去执行提交指令。
rebase的冲突解决
rebase这个动作在去解决那些冲突的时候, 那个过程说白了呢, 就是每一个一个地去把打上去的补丁里面的各种冲突给解决掉的一个过程。
在搞定了一个补丁应用当中的冲突之后, 去执行下面提到的那个命令, 把这个冲突已经解决的事情给标记一下, 说白了就是把你修改完的那些内容, 塞进到缓存里头去。这个操作其实就是在说, 冲突的问题咱们现在处理完了, 把新的改动存好。
注意一下, 那个减号开头接着字母u的-u参数, 它的作用的意思就是把已经跟踪过的文件的新的修改的内容加入到缓存里面去, 但是它不会把那些新添加的文件也加入到缓存中。
接着实施接下来所要执行的命令以继续进行rebase操作, 具体而言即为执行下述的相关指令内容。
如果出现了冲突情况, 那就继续去解决这些冲突, 然后重复地进行上面提到来的这些步骤, 一直持续操作下去, 直到rebase这个环节彻底完成。
如果在中间过程中发现有一个补丁是不需要去应用它的, 那么可以依靠下面提供的这些命令来对它忽略掉。
如果希望回到rebase执行之前的状态, 可以通过执行的命令实现。
这里需要特别说明一下, 在完成了 rebase 操作之后，大家是不需要再去执行 commit 这个步骤的, 同时也没有任何新的修改内容是需要进行提交的, 整个过程实际上全都是让 git 自行全自动处理完成的。
当你遇到编辑冲突的问题时, 你可以选择直接对发生冲突的文件进行编辑操作。
等那个冲突的事情发生了之后, 你去看那个文件系统里面发生了冲突的文件。也就是这里提到的test.txt这个文件。你会发现它里面的内容显示成了有点像下面这样子的一个情况。
在这个时刻, 并没有出现其余的垃圾文件。
最简单的编辑冲突的办法, 就是直接去编辑那个发生了冲突的文件（也就是 test.txt）, 把那些用来标记冲突的符号给删掉, 把冲突的地方解决正确。
通过借助图形界面的管理工具来实施对冲突情形的解决操作。
如果所要去解决的冲突的数量很多, 而且其情况是比较复杂的, 那么图形界面的冲突解决工具的重要性就显得非常突出了。
执行git mergetool用预先配置的Beyond Compare解决冲突：
$ git mergetool
Merging:
test.txt
Normal merge conflict for 'test.txt':
{local}: modified
在远程这个地方, 进行了修改这个动作。
在上面这三个窗口当中, 它们的顺序依次是“LOCAL”、“BASE”和“REMOTE”, 对于这些窗口而言, 它们的作用仅仅是为了解决冲突时提供相应的参考信息, 因此这些窗口是无法被编辑的。
下面会弹出一个窗口, 这个窗口显示的是合并之后的结果, 你可以对其进行手工修改, 也可以点击对应颜色的箭头符号, 从“LOCAL”或者“REMOTE”这两个选项当中去做出选择。
当在Beyond Compare这款工具里完成对冲突内容的修改并进行保存操作以后, 原先存在于冲突文件test.txt中的那些用来标记冲突的特殊符号就会消失不见, 取而代之的是被更新并修改好的内容数据, 至此而言, 针对某个特定文件所进行的冲突协调与编辑流程就可以算是彻底结束了。
在程序启动了Beyond Compare这个软件应用以后, 系统就会自动地创建出来了好几个辅助性的文件, 这些文件的名称里面同时包括了大写的英文字母以及数字编号。
当你结束Beyond Compare这个软件的工作的时候, 那些充当辅助作用的多个档案文件会被系统自动清理掉, 同时呢, 还会产生出来一个名字叫做test.txt.orig的文件, 里面存放的是在解决任何矛盾之前出现的冲突状况记录。
默认该.orig文件可能不会自动删除，需要手动删掉。
