tk-merge-conflict

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Resolve Merge Conflicts

解决合并冲突

Apply only during an active
merge
,
rebase
,
cherry-pick
, or
revert
with conflicts. Never apply to ordinary edits or operations that have not started.
仅在存在冲突的活跃
merge
rebase
cherry-pick
revert
操作期间应用。 切勿应用于普通编辑或尚未启动的操作。

Contract

约定

Before editing, inspect the operation state,
git status
, unmerged index entries, all conflict markers, and both primary sources. If the operation goal and primary sources do not determine intent, never guess; stop as
Blocked
. If required state or evidence cannot be read, the result is
Unverifiable
.
First, check only for an active operation marker and unmerged index entries. If neither exists, report
Blocked: no active conflict
once and stop without inspecting sources, markers, or checks.
Use
Pass
only after confirming every completion signal in the command evidence. Editing only the conflicted files is incomplete.
编辑前,检查操作状态、
git status
、未合并的索引条目、所有冲突标记以及两个主要来源。如果操作目标和主要来源无法确定意图,切勿猜测;以
Blocked
状态停止。如果无法读取所需状态或证据,结果为
Unverifiable
首先,仅检查是否存在活跃操作标记和未合并的索引条目。如果两者都不存在,仅报告一次
Blocked: no active conflict
,然后停止,无需检查来源、标记或其他内容。
仅在确认命令证据中的所有完成信号后,才能使用
Pass
状态。仅编辑冲突文件视为未完成。

🔴 Checkpoint · 🛑 Stop · Resolve/Continue Boundary

🔴 检查点 · 🛑 停止 · 解决/继续边界

Never
finalize
,
stage
,
continue
, or
abort
before proving the operation state, all conflict hunks, both primary sources, and the basis for the resolution. Without that basis, the result is
Blocked
. If the evidence requires choosing between incompatible requirements, record the tradeoff and continue.
在证明操作状态、所有冲突块、两个主要来源以及解决方案的依据之前,切勿
finalize
stage
continue
abort
。若无该依据,结果为
Blocked
。如果证据要求在不兼容的需求之间做出选择,请记录权衡方案并继续。

Workflow

工作流程

  1. operation state
    : Identify the active operation's
    kind
    /
    state
    .
  2. conflict inventory
    : List conflict paths/hunks and unmerged index entries.
  3. intent evidence
    : Map each hunk and both primary sources to intent/evidence.
  4. resolution
    : Edit only conflict files whose hunks are supported by evidence.
  5. stage and verify
    : Prove markers and unmerged entries are gone, stage the exact paths, and run relevant verification.
  6. continue
    : Run the operation-specific continue command and record the result.
  7. receipt
    : Return
    Pass | Fail | Blocked | Unverifiable
    , unverified items, and references to the
    operation
    /
    verification
    /
    follow-up
    sections without copying them.
  1. operation state
    :识别活跃操作的
    kind
    /
    state
  2. conflict inventory
    :列出冲突路径/块和未合并的索引条目。
  3. intent evidence
    :将每个块和两个主要来源映射到意图/证据。
  4. resolution
    :仅编辑有证据支持的冲突块所在的文件。
  5. stage and verify
    :证明标记和未合并条目已消失,暂存确切路径,并运行相关验证。
  6. continue
    :运行特定于操作的继续命令并记录结果。
  7. receipt
    :返回
    Pass | Fail | Blocked | Unverifiable
    、未验证项以及对
    operation
    /
    verification
    /
    follow-up
    部分的引用,无需复制这些内容。

Resolution
receipt
· Single Evidence Record

解决
receipt
· 单一证据记录

모든 해결 실행은 아래 하나의
receipt
로 남깁니다. 이는 별도 결과 섹션이 아니라
Operation
Resolution
Verification
Follow-up
보고의 단일 증거 기록입니다. 알 수 없는 값은
unavailable
또는
not run
으로 적고 추측하지 않습니다.
text
Operation: <merge | rebase | cherry-pick | revert> / <state + step>
Repository HEAD: <commit>
Conflict paths: <path list | none>
Index / markers: <unmerged count, marker count>
Intent basis: <source refs and hunk mapping | unavailable>
Resolution: <Path | Intent | Result rows>
Staged: <exact paths | none>
Verification: <checks and result | Unverifiable>
Continue: <exact continue command and result | not run>
Follow-up: <remaining work | none>
Status: Pass | Fail | Blocked | Unverifiable
Never proceed without the required preceding output. If new conflicts appear, restart from
conflict inventory
.
Before analyzing intent, map index
stage
1/2/3 to the actual base, current commit, and operation target/replayed commit, and record commit IDs/paths. Especially for
rebase
/
cherry-pick
/
revert
, never infer the user's branch or desired behavior from
ours
/
theirs
alone; use operation metadata and actual commit contents.
所有解决操作都将记录为以下一份
receipt
。这并非单独的结果章节,而是
Operation
Resolution
Verification
Follow-up
报告中的单一证据记录。未知值填写为
unavailable
not run
,不得猜测。
text
Operation: <merge | rebase | cherry-pick | revert> / <state + step>
Repository HEAD: <commit>
Conflict paths: <path list | none>
Index / markers: <unmerged count, marker count>
Intent basis: <source refs and hunk mapping | unavailable>
Resolution: <Path | Intent | Result rows>
Staged: <exact paths | none>
Verification: <checks and result | Unverifiable>
Continue: <exact continue command and result | not run>
Follow-up: <remaining work | none>
Status: Pass | Fail | Blocked | Unverifiable
若无所需的前置输出,切勿继续。如果出现新冲突,从
conflict inventory
步骤重新开始。
在分析意图之前,将索引
stage
1/2/3映射到实际的基准、当前提交以及操作目标/重放提交,并记录提交ID/路径。特别是对于
rebase
/
cherry-pick
/
revert
,切勿仅从
ours
/
theirs
推断用户的分支或期望行为;请使用操作元数据和实际提交内容。

Command Evidence

命令证据

EvidenceCommand contractCompletion signalFailure path
Operation stateCheck
MERGE_HEAD
,
rebase-merge
,
rebase-apply
,
CHERRY_PICK_HEAD
, and
REVERT_HEAD
via
git rev-parse --git-path
, then inspect only resolved paths.
Exactly one active operation kind and step match the status/worktree metadata.Conflicting or unreadable markers are
Unverifiable
; do not infer from
.git/
paths.
Operation/indexInspect
git status --short --branch
,
git diff --name-only --diff-filter=U
, and
git ls-files -u
together.
Kind, step, and HEAD match the freshness anchor, with no unreviewed paths.Rebuild the inventory; unexplained state is
Unverifiable
.
MarkersSearch every tracked conflict path for `^(<<<<<<<=======>>>>>>>)`.
StagingRun
git add -- <supported-path...>
, then recheck the
staged diff
and unmerged index.
Only evidence-supported paths are staged, and unmerged entries are zero.Staging failure or remaining entries are
Fail
; do not continue.
VerificationRun relevant tests, builds, and static checks.Record commands, results, and scope, with no change-related failures.If unavailable,
Unverifiable
; if failed,
Fail
.
ContinueRun exactly one matching
git merge --continue
,
git rebase --continue
,
git cherry-pick --continue
, or
git revert --continue
.
The operation finishes as intended without new conflicts.Record the failure/new inventory and restart.
证据命令约定完成信号失败路径
操作状态通过
git rev-parse --git-path
检查
MERGE_HEAD
rebase-merge
rebase-apply
CHERRY_PICK_HEAD
REVERT_HEAD
,然后仅检查已解析路径。
恰好有一种活跃操作类型和步骤与状态/工作树元数据匹配。冲突或无法读取的标记为
Unverifiable
;切勿从
.git/
路径推断。
操作/索引同时检查
git status --short --branch
git diff --name-only --diff-filter=U
git ls-files -u
类型、步骤和HEAD与新鲜度锚点匹配,且无不审查路径。重新构建清单;无法解释的状态为
Unverifiable
标记在每个已跟踪的冲突路径中搜索`^(<<<<<<<=======>>>>>>>)`。
暂存运行
git add -- <supported-path...>
,然后重新检查
staged diff
和未合并索引。
仅暂存有证据支持的路径,且未合并条目数量为零。暂存失败或存在剩余条目为
Fail
;切勿继续。
验证运行相关测试、构建和静态检查。记录命令、结果和范围,且无变更相关失败。若不可用,标记为
Unverifiable
;若失败,标记为
Fail
继续运行恰好一个匹配的
git merge --continue
git rebase --continue
git cherry-pick --continue
git revert --continue
操作按预期完成且无新冲突。记录失败/新清单并重新开始。

Operation Freshness Gate

操作新鲜度检查

From the first inventory, pin the operation kind, HEAD, Git-provided step/target, unmerged paths, and existing
staged
paths. Stage only paths included in the resolution evidence. Add new paths only after the inventory records their reason and intent basis.
Before verification/continue, reread metadata, HEAD, status, and index. If the operation disappears, its kind/step/HEAD changes, or unreviewed unmerged/
staged
content appears, the prior resolution is stale. Rebuild the inventory, evidence, and verification. Unknown drift is
Unverifiable
; do not claim that a disappeared operation was completed by this run.
Primary sources include commit messages,
issue
/
PR
,
spec
/
ticket
, adjacent tests, and established branch behavior. Preserve both intents when compatible. Otherwise, choose based on the operation goal/evidence, report the tradeoff, and do not invent new behavior.
An explicit conflict-resolution request authorizes completing the active operation, but does not automatically authorize
abort
,
reset --hard
,
clean
, force
push
, ordinary
push
, unsupported bulk deletion, or unrelated formatting changes.
从首次清单开始,固定操作类型、HEAD、Git提供的步骤/目标、未合并路径和现有
staged
路径。仅暂存包含在解决证据中的路径。仅在清单记录其原因和意图依据后,才能添加新路径。
在验证/继续之前,重新读取元数据、HEAD、状态和索引。如果操作消失、其类型/步骤/HEAD变更,或出现未审查的未合并/
staged
内容,则先前的解决方案已过期。重新构建清单、证据和验证。未知的变更为
Unverifiable
;切勿声称已完成的操作是由本次运行完成的。
主要来源包括提交消息、
issue
/
PR
spec
/
ticket
、相邻测试和已确立的分支行为。当意图兼容时,保留两者的意图。否则,根据操作目标/证据进行选择,报告权衡方案,切勿创造新行为。
明确的冲突解决请求授权完成活跃操作,但不自动授权
abort
reset --hard
clean
、强制
push
、普通
push
、不支持的批量删除或无关的格式变更。

Completion Report

完成报告

비어 있지 않은 섹션만
Operation
,
Resolution
,
Verification
,
Follow-up
순서로 사용합니다.
Operation
kind
,
state
,
stage
,
status
, 미검증 항목,
reference
,
continue
결과를 소유하고,
Resolution
은 충돌, 의도, 선택 결과를 소유하며,
Verification
은 테스트·표식·인덱스 검사를 소유합니다.
Follow-up
에는 남은 작업만 적습니다. 원격 반영에는 별도 요청이 필요합니다.
해결한 충돌 경로가 여러 개면
Resolution
을 간결한
Path | Intent | Result
표로 표시하고, 사용자에게 중요한 행이 하나면 문장으로 씁니다. 해결 결과부터 시작하며 해결 행을 반복하거나 메타데이터를 덧붙이지 않습니다. 복합 의도, 해결한 경로 묶음, 검증을 25개의 짧은 행/글머리표로 요약합니다. 경로가 8개 이상이면 상위 57개의 의도/결과 행으로 묶고 정확한 나머지 경로를 인용합니다. 할당량이 아니라 예산을 사용합니다.
仅使用非空章节,顺序为
Operation
Resolution
Verification
Follow-up
Operation
包含
kind
state
stage
status
、未验证项、
reference
continue
结果;
Resolution
包含冲突、意图、选择结果;
Verification
包含测试、标记、索引检查。
Follow-up
仅填写剩余工作。远程提交需单独请求。
若解决的冲突路径有多个,将
Resolution
以简洁的
Path | Intent | Result
表格呈现;若仅一行对用户重要,则以句子形式呈现。从解决结果开始,不得重复解决步骤或添加元数据。将复合意图、已解决路径组、验证内容用25个简短条目/项目符号总结。若路径超过8个,将前57个意图/结果条目分组,并引用准确的剩余路径。按需使用,而非按固定配额。