git 冲突解决

冲突的产生

很多命令都可能出现冲突,但从根本上来讲,都是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:    b.c
    both deleted:   origin-name.c
    added by them:  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
Automatic merge failed; 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
=======
b45678910
>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c
其中:冲突标记<<<<<<< (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 冲突的最佳实践 在团队协作开发过程中,Git 冲突是一个常见的现象。当多个开发者在同一文件的不同分支上修改同一部分代码并尝试将其合并到同一个分支时,可能会发生冲突。以下是详细的解决方案: #### 打开冲突文件 当执行 `git merge` 或 `git rebase` 命令时,如果存在冲突,Git 将暂停操作并将冲突标记插入受影响的文件中。此时可以使用任意文本编辑器打开这些文件,查看具体的冲突区域。 #### 识别 Git 的冲突标记 Git 使用特定的标记来表示冲突的部分: - `<<<<<<< HEAD`: 表示当前分支上的代码。 - `=======`: 分隔符,用于区分两个分支的内容。 - `>>>>>>> branch-name`: 表示即将被合并的分支上的代码[^1]。 例如,在一个冲突文件中可能看到如下内容: ```text <<<<<<< HEAD 这是当前分支的代码。 ======= 这是另一个分支的代码。 >>>>>>> ``` #### 解决冲突的方式 可以通过以下几种方法之一来解决冲突: 1. **保留当前分支的更改**:删除其他分支的代码及其对应的冲突标记,仅保留当前分支的代码。 2. **采用另一分支的更改**:删除当前分支的代码及其冲突标记,仅保留另一分支的代码。 3. **手动合并代码**:根据需求将两者的改动结合起来,并移除所有的冲突标记。 完成上述任一操作后,保存文件。 #### 完成冲突解决后的后续步骤 一旦解决了所有冲突,需要通知 Git 文件已修复。这通过运行以下命令实现: ```bash git add <file-with-conflict> ``` 接着继续完成合并或变基过程: - 对于合并操作,运行 `git commit` 来提交合并结果。 - 对于变基操作,则运行 `git rebase --continue` 继续应用剩余补丁。 #### 使用图形化工具辅助解决冲突 除了手动编辑外,还可以利用专门设计的合并工具(如 VS Code、Sourcetree、Meld 等)帮助可视化地比较差异并快速选择合适的变更项。 #### 避免常见误区 值得注意的是,尽管 Git 提供了极大的灵活性,但如果沿用传统的版本控制系统思维模式(比如 SVN 或 Perforce),则可能导致不必要的复杂性和低效的操作流程。因此建议遵循针对 Git 特性的最佳实践指导原则,从而简化日常任务并提高工作效率[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值