---
title: 冲突处理
navTitle: 冲突处理
---
# 冲突处理

冲突表示本地和服务器都修改了同一个资源，SuccApp 不能自动判断应保留哪一侧。AI 修改元数据后更容易出现“看起来只是格式化、实际覆盖了别人修改”的情况，处理冲突时不要急着推送，先看清两边分别改了什么。

## 什么情况下会产生冲突{#when}

常见场景包括：

1. 本地修改了某个文件，服务器上同一个文件也被其他人修改了。
2. 本地删除了文件，服务器上同一个文件被修改了。
3. 本地和服务器都修改了同一个目录级 `.meta` 中的资源元信息。
4. 拉取服务器变化时，SuccApp 无法自动合并两边内容。

如果只是服务器上有新变化，但本地没有修改同一个资源，通常不算冲突，可以直接拉取。

## 处理前检查{#before}

处理冲突前建议先确认：

1. 当前连接的是测试服务器还是生产服务器。
2. Git 中是否已经提交或暂存本地重要修改。
3. Changes 视图中哪些文件带有冲突标记。
4. 服务器上的变化是谁产生的、是否需要保留。
5. 本次任务是否允许覆盖服务器变化。

生产环境出现冲突时，应暂停操作并联系项目负责人确认。

## 查看本地和服务器差异{#diff}

可以通过 Changes 视图打开冲突文件的差异对比。检查时重点看：

1. 本地修改是否属于本次任务。
2. 服务器修改是否属于其他成员的有效修改。
3. 是否有误删、格式化噪声或目录级 `.meta` 异常变化。
4. 两边修改能否同时保留。

如果无法判断业务含义，不要直接选择覆盖，应先和相关成员确认。

## 选择处理方式{#resolution}

冲突通常有三种处理方式：

| 方式 | 适用场景 |
| :--- | :--- |
| 保留本地版本 | 确认本地修改应覆盖服务器当前内容 |
| 采用服务器版本 | 确认服务器内容正确，本地修改不再需要 |
| 手工合并 | 本地和服务器两边修改都需要保留 |

正式项目中，建议优先通过人工判断和 Git 记录确认来源，不要只看文件时间决定保留哪一侧。

## 手工合并冲突标记{#markers}

拉取发生冲突时，文件内容中可能出现类似标记。下面示例为了避免被 Git 误判为未处理冲突，在标记行前加了一个空格；实际文件中标记通常位于行首。

```text
 <<<<<<< Local
本地内容
 =======
服务器内容
 >>>>>>> Remote
```

处理步骤：

1. 打开对应文件。
2. 判断最终应该保留的内容。
3. 删除冲突标记，例如以连续小于号、连续等号或连续大于号开头的行。
4. 保留最终需要生效的内容。
5. 保存文件。
6. 刷新 SuccApp 同步状态。

包含未解决冲突标记的文件不能继续 push。这样可以避免把冲突文本推送到服务器。

## 处理后检查{#after}

冲突处理完成后，请检查：

1. 文件中没有残留冲突标记。
2. Changes 视图中没有未处理冲突。
3. diff 结果符合最终决定。
4. 可以在测试服务器推送并验证。
5. Git 提交信息说明了冲突处理结果。

如果处理过程中发现本地修改不应继续保留，可以通过 SuccApp 放弃修改，或通过 Git 回退本地文件。两者区别请阅读[修改、对比、拉取与推送](../workspace/sync-changes.md#discard)。

## 推荐做法{#recommended}

多人协作项目中，建议遵守：

1. 开始工作前先拉取 Git 和服务器变化。
2. 避免多人同时修改同一个元数据文件。
3. push 被远端变化阻止时先看差异，不直接强制推送。
4. 合并冲突后先推送测试环境验证，再提交 Git。
5. 生产环境冲突必须走发布负责人确认。