冲突处理

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

什么情况下会产生冲突

常见场景包括：

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

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

处理前检查

处理冲突前建议先确认：

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

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

查看本地和服务器差异

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

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

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

选择处理方式

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

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

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

手工合并冲突标记

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

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

处理步骤：

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

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

处理后检查

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

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

如果处理过程中发现本地修改不应继续保留，可以通过 SuccApp 放弃修改，或通过 Git 回退本地文件。两者区别请阅读修改、对比、拉取与推送。

推荐做法

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

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