resolve-conflicts

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Conflict Resolution

Git 合并冲突解决

Resolve Git merge conflicts by intelligently combining changes from both branches while preserving the intent of both changes. This skill follows a plan-first approach: assess conflicts, create a detailed resolution plan, get approval, then execute.

通过智能合并两个分支的更改并保留双方更改的意图来解决Git合并冲突。此Skill遵循“先规划再执行”的方法：评估冲突、制定详细的解决计划、获得批准，然后执行。

Core Principles

核心原则

Plan Before Executing: Always create a structured resolution plan and get user approval before making changes
Prefer Both Changes: Default to keeping both changes unless they directly contradict
Merge, Don't Choose: Especially for imports, tests, and configuration
Regenerate Generated Files: Never manually merge generated files - always regenerate them from their sources
Backup Before Resolving: For deleted-modified files, create backups first
Validate with Tests: Always run tests after resolution
Explain All Resolutions: For each conflict resolved, provide a one-line explanation of the resolution strategy
Ask When Unclear: When the correct resolution isn't clear from the diff, present options to the user and ask for their choice

先规划再执行：在进行更改前，务必制定结构化的解决计划并获得用户批准
优先保留双方更改：除非更改直接矛盾，否则默认保留双方的更改
合并而非选择：尤其适用于导入项、测试文件和配置文件
重新生成自动生成的文件：切勿手动合并自动生成的文件——始终从其源文件重新生成
解决前先备份：对于已删除但被修改的文件，先创建备份
通过测试验证：解决冲突后务必运行测试
解释所有解决方式：对于每个已解决的冲突，提供一行关于解决策略的说明
不确定时询问：如果从差异中无法确定正确的解决方式，向用户提供选项并请求其选择

Workflow

工作流

Step 1: Assess the Conflict Situation

步骤1：评估冲突情况

Run initial checks to understand the conflict scope:

bash

git status

Identify and categorize all conflicted files:

Regular file conflicts (both modified)
Deleted-modified conflicts (one deleted, one modified)
Generated file conflicts (lock files, build artifacts, generated code)
Test file conflicts
Import/configuration conflicts
Binary file conflicts

For each conflicted file, gather information:

File type and purpose
Nature of the conflict (content, deletion, type change)
Scope of changes (lines changed, sections affected)
Whether the file is generated or hand-written

运行初始检查以了解冲突范围：

bash

git status

识别并分类所有冲突文件：

常规文件冲突（双方均已修改）
删除-修改冲突（一方删除，另一方修改）
自动生成文件冲突（锁文件、构建产物、自动生成代码）
测试文件冲突
导入/配置冲突
二进制文件冲突

为每个冲突文件收集信息：

文件类型和用途
冲突性质（内容、删除、类型变更）
更改范围（修改的行数、受影响的部分）
文件是自动生成还是手动编写

Step 2: Create Merge Resolution Plan

步骤2：制定合并解决计划

Based on the assessment, create a structured plan before resolving any conflicts. Present the plan in the following markdown format:

markdown

undefined

基于评估结果，在解决任何冲突前制定结构化计划。请以以下Markdown格式呈现计划：

markdown

undefined

Merge Resolution Plan

合并解决计划

Conflict Summary

冲突摘要

Total conflicted files: [N]
Deleted-modified conflicts: [N]
Generated files: [N]
Regular conflicts: [N]

冲突文件总数：[N]
删除-修改冲突数：[N]
自动生成文件数：[N]
常规冲突数：[N]

Resolution Strategy by File

按文件划分的解决策略

1. [File Path]

1. [文件路径]

Conflict Type: [deleted-modified / generated / imports / tests / code logic / config / struct / binary] Strategy: [Brief description of resolution approach] Rationale: [Why this strategy is appropriate] Risk: [Low/Medium/High] - [Brief risk description] Action Items:

[Specific action 1]
[Specific action 2]

冲突类型：[删除-修改 / 自动生成 / 导入项 / 测试 / 代码逻辑 / 配置 / 结构体 / 二进制] 策略：[解决方法的简要描述] 理由：[此策略合适的原因] 风险：[低/中/高] - [风险简要描述] 行动项：

[具体行动1]
[具体行动2]

2. [File Path]

2. [文件路径]

...

Execution Order

执行顺序

Phase 1: Deleted-Modified Files - Handle deletions and backups first
Phase 2: Generated Files - Regenerate from source
Phase 3: Low-Risk Merges - Imports, tests, documentation
Phase 4: High-Risk Merges - Code logic, configuration, structs
Phase 5: Validation - Compile, test, verify

阶段1：删除-修改文件 - 先处理删除和备份
阶段2：自动生成文件 - 从源文件重新生成
阶段3：低风险合并 - 导入项、测试、文档
阶段4：高风险合并 - 代码逻辑、配置、结构体
阶段5：验证 - 编译、测试、验证

Questions/Decisions Needed

需要的问题/决策

[File/Decision]: [Question for user] (Options: 1, 2, 3)

[文件/决策]：[向用户提出的问题]（选项：1、2、3）

Validation Steps

验证步骤

Run conflict validation script
Compile project
Run test suite
Manual verification of high-risk changes


**Present this plan to the user** and wait for their approval before proceeding with resolution. If there are any unclear conflicts where you need user input, list them in the "Questions/Decisions Needed" section.

**For a complete example plan**, see `references/sample-plan.md`.

运行冲突验证脚本
编译项目
运行测试套件
手动验证高风险更改


**将此计划呈现给用户**，并在开始解决前等待其批准。如果存在任何需要用户输入的不明确冲突，请将其列在“需要的问题/决策”部分。

**完整的计划示例**，请参阅 `references/sample-plan.md`。

Step 3: Handle Deleted-Modified Files

步骤3：处理删除-修改文件

Execute this phase only after the plan is approved.

If there are deleted-but-modified files (status: DU, UD, DD, UA, AU):

bash

.forge/skills/resolve-conflicts/scripts/handle-deleted-modified.sh

This script will:

Create timestamped backups of modified content
Analyze potential relocation targets
Generate analysis reports for each file
Automatically resolve the deletion status

Review the backup directory and analysis files to understand where changes should be applied.

仅在计划获批后执行此阶段。

如果存在已删除但被修改的文件（状态：DU、UD、DD、UA、AU）：

bash

.forge/skills/resolve-conflicts/scripts/handle-deleted-modified.sh

此脚本将：

创建带时间戳的修改内容备份
分析潜在的迁移目标
为每个文件生成分析报告
自动解决删除状态

查看备份目录和分析文件，以了解更改应应用到的位置。

Step 4: Execute Resolution Plan

步骤4：执行解决计划

Follow the execution order defined in your plan. For each conflicted file, apply the appropriate resolution pattern according to your plan. For every conflict you resolve, provide a one-line explanation of how you're resolving it.

As you complete each action item in your plan, mark it as done and report progress to the user.

按照计划中定义的执行顺序操作。 对于每个冲突文件，根据计划应用相应的解决模式。对于每个您解决的冲突，请提供一行说明您如何解决它。

完成计划中的每个行动项后，标记为已完成并向用户报告进度。

When Resolution is Unclear

解决方式不明确时

When you cannot determine the correct resolution from the diff alone (these should already be listed in your plan's "Questions/Decisions Needed" section):

Present the conflict to the user with the conflicting code from both sides
Provide numbered options for resolution (Option 1, Option 2, etc.)
Explain each option clearly with what it would do
Ask the user to choose an option number or provide additional information
Remember their choice and apply similar reasoning to subsequent related conflicts

Example interaction:

I found a conflict in src/main.rs where both branches modify the `calculate_price` function:

<<<<<<< HEAD (Current Branch)
fn calculate_price(item: &Item) -> f64 {
    item.base_price * (1.0 + item.tax_rate)
}
=======
fn calculate_price(item: &Item) -> f64 {
    item.base_price + item.tax_amount
}
>>>>>>> feature-branch (Incoming Branch)

I'm not sure which calculation is correct. Please select an option:

**Option 1**: Keep current branch (multiplies base_price by tax_rate)
**Option 2**: Keep incoming branch (adds tax_amount to base_price)
**Option 3**: Keep both approaches with a new parameter
**Option 4**: Provide more context to help me decide

Please respond with "Option 1", "Option 2", "Option 3", or "Option 4", or provide additional information.

Once the user responds, apply their decision and similar logic to related conflicts.

当您仅从差异中无法确定正确的解决方式时（这些应已列在计划的“需要的问题/决策”部分）：

向用户呈现冲突，展示双方的冲突代码
提供编号选项供解决选择（选项1、选项2等）
清晰解释每个选项的作用
请求用户选择选项编号或提供更多信息
记住其选择，并将类似逻辑应用于后续相关冲突

示例交互：

我在 src/main.rs 中发现一个冲突，两个分支都修改了 `calculate_price` 函数：

<<<<<<< HEAD (当前分支)
fn calculate_price(item: &Item) -> f64 {
    item.base_price * (1.0 + item.tax_rate)
}
=======
fn calculate_price(item: &Item) -> f64 {
    item.base_price + item.tax_amount
}
>>>>>>> feature-branch (传入分支)

我不确定哪种计算方式正确。请选择一个选项：

**选项1**：保留当前分支（将base_price乘以税率）
**选项2**：保留传入分支（将tax_amount加到base_price）
**选项3**：保留两种方式并新增一个参数
**选项4**：提供更多上下文以帮助我决策

请回复“选项1”、“选项2”、“选项3”或“选项4”，或提供更多信息。

用户回复后，应用其决策并将类似逻辑应用于相关冲突。

Resolution Patterns

解决模式

For each conflicted file, apply the appropriate resolution pattern:

对于每个冲突文件，应用相应的解决模式：

Imports/Dependencies

导入项/依赖

Goal: Merge all unique imports from both branches.

One-line explanation: "Merging imports by combining unique imports from both branches, removing duplicates, and grouping by module."

Read

references/patterns.md

section "Import Conflicts" for detailed examples.

Quick approach:

Extract all imports from both sides
Remove duplicates
Group by module/package
Follow language-specific style (alphabetize, group std/external/internal)

目标：合并两个分支中所有唯一的导入项。

一行说明：“通过合并两个分支中的唯一导入项、移除重复项并按模块分组来合并导入。”

请参阅

references/patterns.md

中的“导入冲突”部分获取详细示例。

快速方法：

提取双方的所有导入项
移除重复项
按模块/包分组
遵循语言特定的风格（按字母顺序排列，分组标准库/外部库/内部库）

Tests

测试文件

Goal: Include all test cases and test data from both branches.

One-line explanation: "Merging tests by including all test cases from both branches, combining fixtures, and renaming if necessary to avoid conflicts."

Read

references/patterns.md

section "Test Conflicts" for detailed examples.

Quick approach:

Keep all test functions unless they test the exact same thing
Merge test fixtures and setup functions
Combine assertions from both sides
If test names conflict but test different behaviors, rename to clarify

目标：包含两个分支中的所有测试用例和测试数据。

一行说明：“通过包含两个分支中的所有测试用例、合并测试夹具并在必要时重命名以避免冲突来合并测试。”

请参阅

references/patterns.md

中的“测试冲突”部分获取详细示例。

快速方法：

保留所有测试函数，除非它们测试完全相同的内容
合并测试夹具和设置函数
合并双方的断言
如果测试名称冲突但测试不同行为，重命名以明确区分

Generated Files

自动生成文件

Goal: Regenerate any generated files to include changes from both branches.

One-line explanation: "Resolving generated file by regenerating it from source files to incorporate changes from both branches."

Recognition: A file is generated if it:

Is produced by a build tool, compiler, or code generator
Has a source file or configuration that defines it
Contains headers/comments indicating it's auto-generated
Is listed in
```
.gitattributes
```
as generated
Common examples: lock files, protobuf outputs, GraphQL schema files, compiled assets, auto-generated docs

Approach:

Identify the generation source: Determine what command or tool generates the file

Choose either version temporarily (doesn't matter which):

bash

git checkout --ours <generated-file>    # or --theirs

Regenerate from source: Run the appropriate generation command:

bash

# Package manager lock files
cargo update                       # for Cargo.lock
npm install                        # for package-lock.json
yarn install                       # for yarn.lock
bundle install                     # for Gemfile.lock
poetry lock --no-update            # for poetry.lock

# Code generation
protoc ...                         # for protobuf files
graphql-codegen                    # for GraphQL generated code
make generate                      # for Makefile-based generation
npm run generate                   # for npm script-based generation

# Build artifacts
npm run build                      # for compiled/bundled assets
cargo build                        # for Rust build artifacts

Stage the regenerated file:
bash
```
git add <generated-file>
```

When unsure if a file is generated: Check for auto-generation markers in the file header, or ask the user if you should regenerate or manually merge the file.

目标：重新生成任何自动生成的文件，以包含两个分支的更改。

一行说明：“通过从源文件重新生成来解决自动生成文件的冲突，以合并两个分支的更改。”

识别方式：如果文件符合以下条件，则为自动生成文件：

由构建工具、编译器或代码生成器生成
有定义它的源文件或配置
包含表明其为自动生成的头部/注释
在
```
.gitattributes
```
中被列为自动生成
常见示例：锁文件、Protobuf输出、GraphQL模式文件、编译后的资源、自动生成的文档

方法：

识别生成源：确定生成文件的命令或工具

临时选择任一版本（选择哪个无关紧要）：

bash

git checkout --ours <generated-file>    # 或 --theirs

从源文件重新生成：运行相应的生成命令：

bash

# 包管理器锁文件
cargo update                       # 适用于 Cargo.lock
npm install                        # 适用于 package-lock.json
yarn install                       # 适用于 yarn.lock
bundle install                     # 适用于 Gemfile.lock
poetry lock --no-update            # 适用于 poetry.lock

# 代码生成
protoc ...                         # 适用于 Protobuf 文件
graphql-codegen                    # 适用于 GraphQL 生成代码
make generate                      # 适用于基于 Makefile 的生成
npm run generate                   # 适用于基于 npm 脚本的生成

# 构建产物
npm run build                      # 适用于编译/打包后的资源
cargo build                        # 适用于 Rust 构建产物

暂存重新生成的文件：
bash
```
git add <generated-file>
```

不确定文件是否为自动生成时：检查文件头部的自动生成标记，或询问用户应重新生成还是手动合并该文件。

Configuration Files

配置文件

Goal: Merge configuration values from both branches.

One-line explanation: "Merging configuration by including all keys from both branches and choosing appropriate values for conflicts."

Read

references/patterns.md

section "Configuration File Conflicts" for detailed examples.

Quick approach:

Include all keys from both sides
For conflicting values, choose based on:
- Newer/more recent value
- Safer/more conservative value
- Production requirements
Document choice in commit message

When unclear: Ask the user which configuration value to prefer (current vs incoming)

目标：合并两个分支中的配置值。

一行说明：“通过包含两个分支中的所有键并为冲突选择合适的值来合并配置。”

请参阅

references/patterns.md

中的“配置文件冲突”部分获取详细示例。

快速方法：

包含双方的所有键
对于冲突的值，根据以下因素选择：
- 较新/最近的值
- 更安全/保守的值
- 生产环境要求
在提交信息中记录选择

不确定时：询问用户偏好哪个配置值（当前分支 vs 传入分支）

Code Logic

代码逻辑

Goal: Understand intent of both changes and combine if possible.

One-line explanation: "Resolving code logic by analyzing intent: merging if changes are orthogonal, or choosing one approach if they conflict."

Read

references/patterns.md

section "Code Logic Conflicts" for detailed examples.

Quick approach:

Analyze what each branch is trying to achieve
If changes are orthogonal (different concerns), merge both
If changes conflict (same concern, different approach):
- Review commit messages/PRs for context
- Choose the approach that matches requirements
- Test both approaches if unclear
- Document the decision

When unclear: Present both approaches as options to the user with context about what each does

目标：理解双方更改的意图，如果可能则合并。

一行说明：“通过分析意图解决代码逻辑冲突：如果更改互不相关则合并，若冲突则选择一种方法。”

请参阅

references/patterns.md

中的“代码逻辑冲突”部分获取详细示例。

快速方法：

分析每个分支的目标
如果更改互不相关（关注不同方面），则合并双方
如果更改冲突（关注同一方面，方法不同）：
- 查看提交信息/PR以获取上下文
- 选择符合需求的方法
- 若不确定则测试两种方法
- 记录决策

不确定时：向用户展示两种方法作为选项，并说明每种方法的作用

Struct/Type Definitions

结构体/类型定义

Goal: Include all fields from both branches.

One-line explanation: "Merging struct by including all fields from both branches and choosing appropriate types for any conflicting field definitions."

Quick approach:

Merge all fields
If field types conflict, analyze which is more appropriate
Fix all compilation errors from updated struct
Update tests to use new fields

When unclear: Ask the user which type definition is correct if field types conflict

目标：包含两个分支中的所有字段。

一行说明：“通过包含两个分支中的所有字段并为冲突的字段定义选择合适的类型来合并结构体。”

快速方法：

合并所有字段
如果字段类型冲突，分析哪种更合适
修复更新结构体后的所有编译错误
更新测试以使用新字段

不确定时：如果字段类型冲突，询问用户哪种类型定义正确

Step 5: Validate Resolution

步骤5：验证解决结果

After completing all resolution phases in your plan, validate that all conflicts are resolved:

bash

.forge/skills/resolve-conflicts/scripts/validate-conflicts.sh

This script checks for:

Remaining conflict markers (<<<<<<<, =======, >>>>>>>)
Unmerged paths in git status
Deleted-modified conflicts
Merge state files

完成计划中的所有解决阶段后，验证所有冲突是否已解决：

bash

.forge/skills/resolve-conflicts/scripts/validate-conflicts.sh

此脚本检查：

剩余的冲突标记（<<<<<<<, =======, >>>>>>>）
git status 中的未合并路径
删除-修改冲突
合并状态文件

Step 6: Compile and Test

步骤6：编译和测试

Build and test to ensure the resolution is correct (as defined in your plan's validation steps):

bash

undefined

构建并测试以确保解决结果正确（如计划的验证步骤中定义）：

bash

undefined

For Rust projects

适用于 Rust 项目

cargo test

For other projects, use appropriate test command

其他项目请使用相应的测试命令

npm test

pytest

etc.


If tests fail:

1. Review the failure - is it from merged code or conflict resolution?
2. Check if both branches' tests pass individually
3. Fix integration issues between the merged changes
4. Re-run tests until all pass


如果测试失败：

1. 查看失败原因——是来自合并代码还是冲突解决？
2. 检查两个分支的测试是否各自能通过
3. 修复合并更改之间的集成问题
4. 重新运行测试直到全部通过

Step 7: Finalize

步骤7：完成

Once all conflicts are resolved and tests pass, review your completed plan and commit:

bash

undefined

所有冲突解决且测试通过后，检查已完成的计划并提交：

bash

undefined

Review the changes

查看更改

git diff --cached

Commit with descriptive message that references the plan

使用描述性提交信息，引用计划

git commit -m "Resolve merge conflicts: [describe key decisions]

Executed merge resolution plan:

[Phase 1 summary]
[Phase 2 summary]
[Phase 3+ summaries]

Key decisions:

Merged imports from both branches
Combined test cases
Regenerated lock files
[other significant decisions from plan]

Co-Authored-By: ForgeCode noreply@forgecode.dev"

undefined

git commit -m "Resolve merge conflicts: [描述关键决策]

Executed merge resolution plan:

[阶段1摘要]
[阶段2摘要]
[阶段3+摘要]

Key decisions:

Merged imports from both branches
Combined test cases
Regenerated lock files
[计划中的其他重要决策]

Co-Authored-By: ForgeCode noreply@forgecode.dev"

undefined

Decision Tracking

决策跟踪

When you ask the user to choose between options, track their decision and apply similar reasoning to subsequent conflicts:

Example scenario:

First conflict: User chooses Option 1 (prefer current branch's validation logic)
Second similar conflict: Apply the same reasoning (prefer current branch's validation approach)
Mention: "Resolving by keeping current branch's approach (consistent with your earlier choice)"

Key principles:

Remember user preferences within the same conflict resolution session
Apply consistent patterns when conflicts are similar
Mention the consistency: "Following the same pattern as before..."
Ask again if a new conflict is sufficiently different from previous ones

当您要求用户在选项中选择时，跟踪其决策并将类似逻辑应用于后续冲突：

示例场景：

第一个冲突：用户选择选项1（偏好当前分支的验证逻辑）
第二个类似冲突：应用相同逻辑（偏好当前分支的验证方法）
说明：“通过保留当前分支的方法解决（与您之前的选择一致）”

核心原则：

在同一冲突解决会话中记住用户偏好
对类似冲突应用一致的模式
提及一致性：“遵循之前的相同模式...”
如果新冲突与之前的冲突有显著差异，请再次询问

Common Patterns Reference

常见模式参考

For detailed resolution patterns, read:

```
references/patterns.md
```
- Comprehensive examples for all conflict types

Quick pattern lookup:

Imports: Combine all unique imports, group by module
Tests: Keep all tests unless identical, merge fixtures
Generated files: Choose either version, regenerate from source
Config: Merge all keys, choose newer/safer values for conflicts
Code: Analyze intent, merge if orthogonal, choose one if conflicting
Structs: Include all fields from both branches
Docs: Combine all documentation sections

有关详细的解决模式，请参阅：

```
references/patterns.md
```
- 所有冲突类型的综合示例

快速模式查找：

导入项：合并所有唯一导入项，按模块分组
测试：保留所有测试（除非完全相同），合并夹具
自动生成文件：选择任一版本，从源文件重新生成
配置：合并所有键，为冲突选择较新的值
代码：分析意图，互不相关则合并，冲突则选择一种方法
结构体：包含两个分支的所有字段
文档：合并所有部分

Special Scenarios

特殊场景

Binary Files in Conflict

二进制文件冲突

Binary files cannot be merged. Choose one version:

bash

git checkout --ours path/to/binary    # keep our version

二进制文件无法合并。选择一个版本：

bash

git checkout --ours path/to/binary    # 保留我们的版本

or

或

git checkout --theirs path/to/binary # keep their version

undefined

git checkout --theirs path/to/binary # 保留他们的版本

undefined

Mass Rename/Refactoring Conflicts

大规模重命名/重构冲突

If one branch renamed/refactored many files while another modified them:

Accept the rename/refactoring (structural change)
Apply the modifications to the new structure
Use backups from
```
handle-deleted-modified.sh
```
to guide the application

如果一个分支重命名/重构了许多文件，而另一个分支修改了这些文件：

接受重命名/重构（结构变更）
将修改应用到新结构
使用
```
handle-deleted-modified.sh
```
的备份来指导应用

Submodule Conflicts

子模块冲突

bash

undefined

bash

undefined

Check submodule status

检查子模块状态

git submodule status

Update to the correct commit

更新到正确的提交

cd path/to/submodule git checkout <desired-commit> cd ../.. git add path/to/submodule

undefined

cd path/to/submodule git checkout <desired-commit> cd ../.. git add path/to/submodule

undefined

Troubleshooting

故障排除

"Both Added" Conflicts (AA)

“双方均已添加”冲突（AA）

Both branches added a new file with the same name but different content:

Review both versions
If they serve the same purpose, merge their content
If they serve different purposes, rename one

两个分支添加了同名但内容不同的新文件：

查看两个版本
如果用途相同，合并内容
如果用途不同，重命名其中一个

Whitespace-Only Conflicts

仅空格冲突

If conflicts are only whitespace differences:

bash

git merge -Xignore-space-change <branch>

如果冲突仅为空格差异：

bash

git merge -Xignore-space-change <branch>

Persistent Conflict Markers

残留冲突标记

If validation shows conflict markers but you think you resolved them:

Search for the exact marker strings:
```
git grep -n "<<<<<<< HEAD"
```
Some markers might be in strings or comments - resolve those too
Check for hidden characters or encoding issues

如果验证显示存在冲突标记，但您认为已解决：

搜索确切的标记字符串：
```
git grep -n "<<<<<<< HEAD"
```
某些标记可能在字符串或注释中——也需要解决这些
检查隐藏字符或编码问题

Tests Fail After Resolution

解决后测试失败

Test each branch individually to confirm they pass
The failure is likely from interaction between the merged changes
Debug the interaction issue, not the individual changes
Update code to make both changes work together

分别测试每个分支，确认它们各自能通过
失败可能来自合并更改之间的交互
调试交互问题，而非单个更改
更新代码以使双方更改协同工作

Quick Reference Card

快速参考卡

Conflict Type	Strategy	One-line Explanation Template
Imports	Merge all, deduplicate, group by module	"Merging imports by combining unique imports from both branches and grouping by module"
Tests	Keep all, merge fixtures	"Including all test cases from both branches and combining test fixtures"
Generated files	Regenerate from source	"Regenerating [file] from source to include changes from both branches"
Config	Merge keys, choose newer values	"Merging all config keys and choosing [current/incoming] value for [key]"
Code logic	Analyze intent, merge if orthogonal	"Merging both changes as they address different concerns" OR "Choosing [current/incoming] approach for [reason]"
Structs	Include all fields	"Including all fields from both branches in struct definition"
Docs	Combine all sections	"Combining documentation from both branches"
Deleted-modified	Backup, analyze, apply to new location	"Applying modifications to new location after file was moved/renamed"
Binary files	Choose one version	"Keeping [current/incoming] version of binary file"

Remember:

Always provide a one-line explanation for each conflict resolution
When unclear, present numbered options to the user
Track user decisions and apply consistently to similar conflicts
The goal is to preserve the intent and functionality of both branches while creating a cohesive merged result

冲突类型	策略	一行说明模板
导入项	合并所有、去重、按模块分组	"通过合并两个分支的唯一导入项并按模块分组来合并导入"
测试	保留所有、合并夹具	"包含两个分支的所有测试用例并合并测试夹具"
自动生成文件	从源文件重新生成	"从源文件重新生成[文件]以合并两个分支的更改"
配置	合并键、选择较新值	"合并所有配置键并为[键]选择[当前/传入]值"
代码逻辑	分析意图、互不相关则合并	"合并双方更改，因为它们关注不同方面" 或 "选择[当前/传入]方法，原因是[理由]"
结构体	包含所有字段	"在结构体定义中包含两个分支的所有字段"
文档	合并所有部分	"合并两个分支的文档"
删除-修改	备份、分析、应用到新位置	"文件移动/重命名后，将修改应用到新位置"
二进制文件	选择一个版本	"保留二进制文件的[当前/传入]版本"

请记住：

始终为每个冲突解决提供一行说明
不确定时，向用户提供编号选项
跟踪用户决策并一致应用于类似冲突
目标是保留两个分支的意图和功能，同时创建一个连贯的合并结果