fix-conflict

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fix Merge Conflicts

解决合并冲突

This skill automatically resolves merge conflicts for the current PR by fetching the base branch, performing a test merge, analyzing conflicting files, and applying resolutions.

该技能通过拉取基准分支、执行测试合并、分析冲突文件并应用解决方案，自动解决当前PR中的合并冲突。

Usage

使用方法

/fix-conflict           # Auto-resolve merge conflicts
/fix-conflict --dry-run # Show conflicts without resolving

/fix-conflict           # 自动解决合并冲突
/fix-conflict --dry-run # 仅显示冲突，不执行解决操作

Workflow

工作流程

Step 1: Determine PR and Base Branch

步骤1：确定PR与基准分支

Get the current branch and PR details:

bash

git rev-parse --abbrev-ref HEAD

bash

gh pr view --json baseRefName,number,url -q '{base: .baseRefName, number: .number, url: .url}'

If no PR exists, report "No PR found for the current branch. Nothing to resolve." and stop.

获取当前分支及PR详情：

bash

git rev-parse --abbrev-ref HEAD

bash

gh pr view --json baseRefName,number,url -q '{base: .baseRefName, number: .number, url: .url}'

如果不存在PR，则提示“当前分支未关联PR，无需解决冲突”并终止操作。

Step 2: Fetch Latest Remote State

步骤2：拉取最新远程状态

bash

git fetch origin

bash

git fetch origin

Step 3: Attempt Test Merge

步骤3：尝试测试合并

Start a non-committing merge to identify conflicts:

bash

git merge --no-commit --no-ff "origin/<base-branch>"

If the merge completes without conflicts:

Run
```
git merge --abort
```
to undo the test merge
Report "No merge conflicts detected. The PR is mergeable." and stop.

If the merge fails with conflicts, proceed to the next step.

启动不提交的合并操作以识别冲突：

bash

git merge --no-commit --no-ff "origin/<base-branch>"

如果合并完成且无冲突：

执行
```
git merge --abort
```
撤销测试合并
提示“未检测到合并冲突，PR可正常合并”并终止操作。

如果合并失败并出现冲突，则进入下一步。

Step 4: Identify Conflicting Files

步骤4：识别冲突文件

bash

git diff --name-only --diff-filter=U

This lists all files with unresolved conflicts.

For each conflicting file, check if it's a binary file:

bash

file <path>

If binary files have conflicts:

Abort the merge:
```
git merge --abort
```
Report "Binary file conflicts detected in: <files>. These require manual resolution." and stop.

bash

git diff --name-only --diff-filter=U

该命令会列出所有存在未解决冲突的文件。

针对每个冲突文件，检查是否为二进制文件：

bash

file <path>

如果二进制文件存在冲突：

终止合并：
```
git merge --abort
```
提示“检测到二进制文件冲突：<files>。此类冲突需要手动解决”并终止操作。

Step 5: Resolve Conflicts

步骤5：解决冲突

For each conflicting file:

Read the entire file to see the conflict markers (
```
<<<<<<<
```
,
```
=======
```
,
```
>>>>>>>
```
)
Understand the changes from both sides:
- The current branch's changes (between
```
<<<<<<<
```
  and
```
=======
```
  )
- The base branch's changes (between
```
=======
```
  and
```
>>>>>>>
```
  )
Determine the correct resolution:
- If both sides modify different parts of the same function: keep both changes
- If both sides modify the same lines: analyze the intent and merge logically
- If one side adds new code and the other modifies existing: keep both
- If changes are contradictory: prefer the current branch's intent (it's newer work)
Remove all conflict markers and write the resolved content
Stage the resolved file:
```
git add <file>
```

Important constraints:

Never blindly choose one side — always analyze both changes
Preserve formatting and style consistency
If a conflict is too complex to resolve confidently (e.g., large architectural changes on both sides), abort and report for manual resolution

--dry-run

flag is provided: show each conflict with both sides and the proposed resolution, but do NOT modify files, commit, or push.

针对每个冲突文件：

读取整个文件以查看冲突标记（
```
<<<<<<<
```
,
```
=======
```
,
```
>>>>>>>
```
）
分析双方的修改内容：
- 当前分支的修改（位于
```
<<<<<<<
```
  与
```
=======
```
  之间）
- 基准分支的修改（位于
```
=======
```
  与
```
>>>>>>>
```
  之间）
确定正确的解决方案：
- 如果双方修改的是同一函数的不同部分：保留双方修改
- 如果双方修改了相同行：分析修改意图并进行逻辑合并
- 如果一方添加新代码，另一方修改现有代码：保留双方内容
- 如果修改内容相互矛盾：优先保留当前分支的修改（属于较新的工作内容）
删除所有冲突标记并写入解决后的内容
暂存已解决的文件：
```
git add <file>
```

重要约束：

切勿盲目选择某一方的修改——务必分析双方的变更内容
保持格式与风格的一致性
如果冲突过于复杂（例如双方均进行了大规模架构变更），则终止操作并提示需要手动解决

如果提供了

--dry-run

参数：显示每个冲突的双方内容及建议解决方案，但不修改文件、提交或推送。

Step 6: Local Verification

步骤6：本地验证

After resolving all conflicts, verify the merge is clean:

bash

ruff check synapse/ tests/

bash

ruff format synapse/ tests/ --check

bash

pytest

If any check fails:

Attempt one targeted fix for the issue
If it still fails, abort the merge and report what went wrong

解决所有冲突后，验证合并结果是否正常：

bash

ruff check synapse/ tests/

bash

ruff format synapse/ tests/ --check

bash

pytest

如果任何检查失败：

尝试针对该问题进行一次定向修复
如果仍然失败，则终止合并并报告问题原因

Step 7: Complete Merge and Push

步骤7：完成合并并推送

bash

git commit -m "merge: resolve conflicts with <base-branch>"

bash

git push

Report a summary:

Number of files with conflicts resolved
List of resolved files
Whether all local checks pass

bash

git commit -m "merge: resolve conflicts with <base-branch>"

bash

git push

报告总结信息：

已解决冲突的文件数量
已解决冲突的文件列表
所有本地检查是否通过

Step 8: Error Handling

步骤8：错误处理

Abort on failure: If resolution fails at any point, always run
```
git merge --abort
```
to return to a clean state
Binary conflicts: Report and stop — do not attempt to resolve binary files
Too many conflicts (>10 files): Report and suggest manual resolution
Max 1 attempt: This skill attempts resolution once. If it fails, manual intervention is needed
Never force-push: Always use
```
git push
```
, never
```
git push --force
```

失败即终止：如果在任何步骤中解决失败，务必执行
```
git merge --abort
```
以恢复至干净状态
二进制冲突：直接报告并终止操作——不尝试自动解决二进制文件冲突
冲突过多（超过10个文件）：报告并建议手动解决
最多尝试1次：该技能仅尝试一次冲突解决。如果失败，则需要人工介入
禁止强制推送：始终使用
```
git push
```
，切勿使用
```
git push --force
```

Safety

安全性

The test merge (
```
--no-commit --no-ff
```
) ensures we can always abort cleanly
```
git merge --abort
```
is the escape hatch at every step
Local verification (ruff, pytest) before pushing ensures we don't push broken code
Binary files are never auto-resolved

测试合并（
```
--no-commit --no-ff
```
）确保我们始终可以干净地终止操作
```
git merge --abort
```
是所有步骤中的应急退出方式
推送前的本地验证（ruff、pytest）确保不会推送损坏的代码
二进制文件永远不会被自动解决