dx-devops-conflict-resolve

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

DevOps Center Conflict & Deploy-Failure Resolution

DevOps Center冲突与部署失败解决方法

Diagnoses and resolves what blocks a DevOps Center promotion of a work item's feature branch. DevOps Center is Git-backed: each work item is a feature branch and each pipeline stage has a target branch. A promotion can fail two ways — a Git merge conflict (two work items changed the same metadata) or a deployment failure (the deploy itself errors, often on a missing dependency). There is no

sf devops conflict

CLI command; both cases are diagnosed and resolved with standard git against the connected repository. This skill runs in a local clone of that repo.

诊断并解决阻碍DevOps Center提升工作项功能分支的问题。DevOps Center基于Git构建：每个工作项对应一个功能分支，每个流水线阶段对应一个目标分支。提升操作可能因两种原因失败——Git合并冲突（两个工作项修改了相同的元数据）或部署失败（部署本身出错，通常是因为缺少依赖项）。目前没有

sf devops conflict

CLI命令；这两种情况都需要针对关联仓库使用标准git命令进行诊断和解决。此技能在该仓库的本地克隆中运行。

Scope

适用范围

In scope: (a) Detect merge conflicts between a work item's feature branch and the target stage branch (non-destructively), resolve conflicted files (choose a side or manually merge conflict markers), commit, and push the feature branch DevOps Center tracks; (b) Diagnose a promotion deploy failure — classify it as a merge conflict vs. a deploy error, parse a missing dependency, and determine whether a full promotion can fix it (the component exists on the feature branch) or the component must be added first
Out of scope: Running the promotion, full promotion, or combine (use
```
dx-devops-promote
```
), creating/updating work items or their status (use
```
dx-devops-work-item-manage
```
), deploying metadata directly to an org, pipeline or project setup (separate skills)

适用场景：(a) 非破坏性检测工作项功能分支与目标阶段分支之间的合并冲突，解决冲突文件（选择某一方版本或手动合并冲突标记），提交并推送DevOps Center跟踪的功能分支；(b) 诊断提升操作的部署失败——将其归类为合并冲突或部署错误，解析缺失的依赖项，并确定是否可通过完整提升修复（组件已存在于功能分支上）或必须先添加该组件
不适用场景：执行提升、完整提升或合并操作（使用
```
dx-devops-promote
```
），创建/更新工作项或其状态（使用
```
dx-devops-work-item-manage
```
），直接将元数据部署到组织，流水线或项目设置（使用单独的技能）

Required Inputs

必要输入

Gather or infer before proceeding:

Local clone of the DevOps Center connected Git repository (the agent runs git commands here). Confirm the working tree is clean before starting.
Feature branch name — the branch backing the work item. If the user gives a work item ID/subject instead, resolve it to its branch (see the Reference File Index for the
```
sf devops work-item
```
lookup).
Target stage branch name — the branch of the pipeline stage the work item promotes into (e.g. the integration/UAT branch).
Remote name — defaults to
```
origin
```
.
Deploy error text (deploy-failure track only) — the promotion's error output/summary. Needed to classify the failure and parse a missing dependency. Capture it to a file or pipe it into the diagnosis script.

Defaults unless specified:

Remote:
```
origin
```
Merge direction: merge the target stage branch into the feature branch (reconcile the work item with where it is going)

If the user names both branches ("resolve conflicts on

feature/WI-101

against

uat

"), proceed. If they give a work item, resolve its branch first.

在开始前收集或推断以下信息：

DevOps Center关联Git仓库的本地克隆（Agent在此运行git命令）。开始前确认工作树是干净的。
功能分支名称——工作项对应的分支。如果用户提供的是工作项ID/主题，需将其解析为对应的分支（参考参考文件索引中的
```
sf devops work-item
```
查询方法）。
目标阶段分支名称——工作项要提升到的流水线阶段的分支（例如集成/UAT分支）。
远程仓库名称——默认值为
```
origin
```
。
部署错误文本（仅针对部署失败流程）——提升操作的错误输出/摘要。需要此信息来归类失败原因并解析缺失的依赖项。将其保存到文件或管道输入到诊断脚本中。

未指定时的默认值：

远程仓库：
```
origin
```
合并方向：将目标阶段分支合并到功能分支（使工作项与目标状态保持一致）

如果用户指定了两个分支（例如“解决

feature/WI-101

与

uat

之间的冲突”），即可继续。如果用户提供的是工作项，需先解析其对应的分支。

Workflow

工作流程

DevOps Center promotion blockers are Git-level. Detection and diagnosis are deterministic (scripts); resolving each conflicted file requires judgment (prose). Never resolve without first detecting on a clean tree.

Route first. Pick the track from the user's situation:

Merge conflict track — the user wants a pre-promotion conflict check, or a promotion failed and the cause is (or is suspected to be) a merge conflict → Phases 1–4 below.
Deploy-failure track — a promotion's deploy failed with an error message and the user wants to know why and how to fix it → Phase D below. If Phase D classifies the failure as a merge conflict, fall through to the merge-conflict track.

DevOps Center提升操作的阻碍属于Git层面问题。检测和诊断是确定性的（通过脚本）；解决每个冲突文件需要判断（手动操作）。在干净的工作树上检测之前，切勿进行解决操作。

首先选择流程。根据用户的情况选择对应的流程：

合并冲突流程——用户希望在提升前检查冲突，或者提升操作失败且原因是（或疑似）合并冲突 → 执行以下第1-4阶段。
部署失败流程——提升操作的部署步骤失败并显示错误消息，用户想了解原因和解决方法 → 执行以下D阶段。如果D阶段将失败归类为合并冲突，则切换到合并冲突流程。

Phase 1 — Authenticate and orient

阶段1 — 身份验证与定位

Confirm the local repo and clean tree. Run in the repo clone:
bash
```
git rev-parse --is-inside-work-tree && git status --porcelain
```
- If
```
git status --porcelain
```
  prints anything, the tree is dirty — instruct the user to commit or stash first. A trial merge on a dirty tree is unsafe.
Resolve a work item to its branch (only if the user gave a work item, not a branch). Verify org auth with
```
sf org display --json
```
; if it fails, tell the user to run
```
sf org login web --set-default --alias <alias>
```
. Then look up the branch — see
```
references/git-conflict-resolution.md
```
.

确认本地仓库和干净的工作树。在仓库克隆中运行：
bash
```
git rev-parse --is-inside-work-tree && git status --porcelain
```
- 如果
```
git status --porcelain
```
  输出内容，说明工作树不干净——指导用户先提交或暂存更改。在不干净的工作树上进行试验性合并是不安全的。
将工作项解析为对应的分支（仅当用户提供的是工作项而非分支时）。使用
```
sf org display --json
```
验证组织身份验证；如果验证失败，告知用户运行
```
sf org login web --set-default --alias <alias>
```
。然后查询分支——参考
```
references/git-conflict-resolution.md
```
。

Phase 2 — Detect (non-destructive)

阶段2 — 检测（非破坏性）

Run the detection script. It fetches, trial-merges the target branch into the feature branch without committing, lists conflicted files, and aborts the trial so the tree is left untouched:
bash
```
scripts/detect-conflicts.sh <feature-branch> <target-branch> [remote]
```
- Exit
```
0
```
  = clean merge (no conflicts) → report "safe to promote" and STOP.
- Exit
```
2
```
  = conflicts found → the script prints the conflicting file list; proceed to Phase 3.
- Exit
```
1
```
  = error (dirty tree, unknown branch, fetch failure) → report the error and STOP; do not treat an error as "no conflicts".

运行检测脚本。该脚本会拉取代码，将目标分支试验性合并到功能分支但不提交，列出冲突文件，然后中止试验合并以保持工作树不变：
bash
```
scripts/detect-conflicts.sh <feature-branch> <target-branch> [remote]
```
- 退出码
```
0
```
  = 合并干净（无冲突）→ 报告“可安全提升”并停止操作。
- 退出码
```
2
```
  = 发现冲突→ 脚本会打印冲突文件列表；继续执行阶段3。
- 退出码
```
1
```
  = 错误（工作树不干净、未知分支、拉取失败）→ 报告错误并停止操作；请勿将错误视为“无冲突”。

Phase 3 — Resolve

阶段3 — 解决

Start the real merge to bring conflict markers into the working tree:
bash
```
git checkout <feature-branch>
git merge --no-ff <remote>/<target-branch>
```
List the conflicted files deterministically:
bash
```
git diff --name-only --diff-filter=U
```
Resolve each conflicted file — this is the judgment step:
- When one side is unambiguously correct, take it:
```
git checkout --ours -- <file>
```
  (keep the feature branch's version) or
```
git checkout --theirs -- <file>
```
  (take the target branch's version). For DevOps Center, "ours" is the feature branch, "theirs" is the target stage branch.
- When both sides contain needed changes (divergent edits to the same component), open the file and manually merge — reconcile the
```
<<<<<<<
```
  /
```
=======
```
  /
```
>>>>>>>
```
  regions into a single correct version, preserving both intents. Be especially careful with XML metadata (
```
.xml
```
  ,
```
.object-meta.xml
```
  ,
```
.field-meta.xml
```
  ): keep the file well-formed and do not duplicate elements.
- Stage each resolved file:
```
git add <file>
```
  .
Confirm no markers remain before committing:
bash
```
git diff --check
git diff --name-only --diff-filter=U
```
- ```
git diff --check
```
  must report nothing, and the unmerged-file list must be empty. If either shows leftovers, keep resolving — do not commit.

启动实际合并，将冲突标记带入工作树：

bash

git checkout <feature-branch>
git merge --no-ff <remote>/<target-branch>

确定性列出冲突文件：

bash

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

解决每个冲突文件——这是需要判断的步骤：
- 当某一方版本明确正确时，选择该版本：
```
git checkout --ours -- <file>
```
  （保留功能分支的版本）或
```
git checkout --theirs -- <file>
```
  （选择目标阶段分支的版本）。对于DevOps Center，“ours”指功能分支，“theirs”指目标阶段分支。
- 当双方都包含需要的更改（同一组件的不同编辑）时，打开文件并手动合并——将
```
<<<<<<<
```
  /
```
=======
```
  /
```
>>>>>>>
```
  区域协调为单一正确版本，保留双方的意图。处理XML元数据（
```
.xml
```
  、
```
.object-meta.xml
```
  、
```
.field-meta.xml
```
  ）时要特别小心：保持文件格式正确，不要重复元素。
- 暂存每个已解决的文件：
```
git add <file>
```
  。
提交前确认无残留标记：
bash
```
git diff --check
git diff --name-only --diff-filter=U
```
- ```
git diff --check
```
  必须无输出，且未合并文件列表必须为空。如果其中任何一项显示有残留标记，继续解决——不要提交。

Phase 4 — Finalize and report

阶段4 — 完成与报告

Commit and push the resolution to the tracked feature branch so DevOps Center picks it up:

bash

git commit --no-edit          # completes the merge with the default merge message
git push <remote> <feature-branch>

Report the outcome:
- No conflicts: "No merge conflicts between
```
<feature>
```
  and
```
<target>
```
  . Safe to promote."
- Resolved: list the files resolved and how (took a side vs. manual merge), and state that the feature branch was pushed. Then hand off: "Re-validate and promote via
```
dx-devops-promote
```
  ."

提交并推送解决方案到跟踪的功能分支，以便DevOps Center获取：

bash

git commit --no-edit          # 使用默认合并消息完成合并
git push <remote> <feature-branch>

报告结果：
- 无冲突：“
```
<feature>
```
  与
```
<target>
```
  之间无合并冲突。可安全提升。”
- 已解决：列出已解决的文件及解决方式（选择某一方版本或手动合并），并说明功能分支已推送。然后移交：“通过
```
dx-devops-promote
```
  重新验证并提升。”

Phase D — Diagnose a deployment failure

D阶段 — 诊断部署失败

Use this track when a promotion's deploy failed with an error and the user wants to know why and how to fix it. Diagnosis is deterministic (a script); do not eyeball the error.

D1. Capture the deploy error text to a file, or pipe it directly into the diagnosis script.

D2. Run the diagnosis script from the repo clone. It classifies the failure, parses any missing dependency, and checks whether that component exists on the feature branch (via

git show

bash

scripts/diagnose-deploy-failure.sh <error-file|-> <feature-branch> [target-branch] [remote]
# or:  <deploy command> 2>&1 | scripts/diagnose-deploy-failure.sh - <feature-branch> <target-branch>

Act on the exit code and the printed

REASON

RECOMMENDATION

Exit
```
0
```
(
```
dependency_in_feature_branch
```
) → the missing component exists on the feature branch but was left out of the deployed set. A full promotion should fix it. Report this, confirm with the user, and hand off to
```
dx-devops-promote
```
to run a full promotion. This skill does not promote.
Exit
```
2
```
(
```
merge_conflict
```
) → the failure is a merge conflict, not a deploy error. Fall through to the merge-conflict track (Phase 1 onward).
Exit
```
3
```
(
```
dependency_not_in_feature_branch
```
) → the missing component is not on the feature branch, so promoting cannot supply it. Report that the component must be added and committed to the feature branch (or the owning work item included) before promoting.
Exit
```
4
```
(
```
no_dependency_parsed
```
) → the error is not a recognizable missing dependency. Report the raw error and advise fixing the underlying issue (e.g. test coverage, invalid metadata); a full promotion will not help.
Exit
```
1
```
→ environment/usage error (not in a git repo, unreadable error file) → report and stop.

D3. Report the diagnosis with the

REASON

, whether a full promotion can fix it, the missing component (if any) and where it lives, and the concrete next step. Never re-promote blindly — only recommend a full promotion when the diagnosis is

dependency_in_feature_branch

当提升操作的部署步骤失败并显示错误，用户想了解原因和解决方法时，使用此流程。诊断是确定性的（通过脚本）；请勿手动查看错误信息。

D1. 捕获部署错误文本到文件，或直接管道输入到诊断脚本中。

D2. 从仓库克隆中运行诊断脚本。该脚本会归类失败原因，解析任何缺失的依赖项，并检查该组件是否存在于功能分支上（通过

git show

）：

bash

scripts/diagnose-deploy-failure.sh <error-file|-> <feature-branch> [target-branch] [remote]
# 或：  <deploy command> 2>&1 | scripts/diagnose-deploy-failure.sh - <feature-branch> <target-branch>

根据退出码和打印的

REASON

RECOMMENDATION

执行操作：

退出码
```
0
```
（
```
dependency_in_feature_branch
```
）→ 缺失的组件存在于功能分支上但未包含在部署集中。完整提升操作应能修复此问题。报告此情况，与用户确认，然后移交到
```
dx-devops-promote
```
执行完整提升。此技能不执行提升操作。
退出码
```
2
```
（
```
merge_conflict
```
）→ 失败原因是合并冲突，而非部署错误。切换到合并冲突流程（从阶段1开始）。
退出码
```
3
```
（
```
dependency_not_in_feature_branch
```
）→ 缺失的组件不存在于功能分支上，因此提升操作无法提供该组件。报告必须先将组件添加并提交到功能分支（或包含其所属的工作项），然后才能进行提升。
退出码
```
4
```
（
```
no_dependency_parsed
```
）→ 错误无法识别为缺失依赖项。报告原始错误并建议修复根本问题（例如测试覆盖率、无效元数据）；完整提升操作无济于事。
退出码
```
1
```
→ 环境/使用错误（不在git仓库中、错误文件不可读）→ 报告错误并停止操作。

D3. 报告诊断结果，包括

REASON

、完整提升是否可修复问题、缺失组件（如有）及其位置，以及具体的下一步操作。切勿盲目重新提升——仅当诊断结果为

dependency_in_feature_branch

时，才建议执行完整提升。

Rules / Constraints

规则 / 约束

Constraint	Rationale
Never trial-merge or merge on a dirty working tree	An in-progress merge on uncommitted changes can clobber the user's work irrecoverably
Always detect (Phase 2) before resolving (Phase 3)	Detection is non-destructive; jumping to a live merge without knowing the conflict set risks a messy half-merge
Detect conflicts with the script, not by eyeballing	`scripts/detect-conflicts.sh` produces a deterministic, reproducible conflict list and always cleans up its trial merge
A non-zero detection error is NOT "no conflicts"	Only exit `0` (clean) means safe to promote; exit `1` means the check failed and must be reported
Merge the target stage branch INTO the feature branch	Reconciles the work item with its destination; DevOps Center promotes the feature branch, so the resolution must live there
Verify no conflict markers remain ( `git diff --check` ) before committing	Committing unresolved markers corrupts the metadata and the promotion
Preserve XML well-formedness when manually merging metadata	Malformed `-meta.xml` breaks deployment; never leave duplicated or truncated elements
Push only the work item's feature branch	The resolution belongs to the work item's branch; never push to a stage/integration branch directly
This skill does not promote or deploy	Resolution ends at a pushed, conflict-free branch or a diagnosis; promotion (including full promotion) is `dx-devops-promote`
Diagnose deploy failures with the script, not by eyeballing	`scripts/diagnose-deploy-failure.sh` deterministically classifies the failure and verifies branch presence with `git show`
Recommend a full promotion ONLY when the missing component is on the feature branch	If the component is absent, promoting the branch cannot supply it — a re-promote just fails again

约束	理由
切勿在不干净的工作树上进行试验性合并或实际合并	在未提交的更改上进行合并可能会不可挽回地覆盖用户的工作
解决（阶段3）前必须先进行检测（阶段2）	检测是非破坏性的；在不知道冲突集的情况下直接进行实时合并可能会导致混乱的半合并状态
使用脚本检测冲突，而非手动查看	`scripts/detect-conflicts.sh` 会生成确定性、可重现的冲突列表，并始终清理其试验性合并
非零检测错误不等于“无冲突”	只有退出码 `0` （干净）表示可安全提升；退出码 `1` 表示检查失败，必须报告
将目标阶段分支合并到功能分支	使工作项与目标状态保持一致；DevOps Center提升的是功能分支，因此解决方案必须在该分支上
提交前验证无冲突标记残留（ `git diff --check` ）	提交未解决的标记会损坏元数据和提升操作
手动合并元数据时保持XML格式正确	格式错误的 `-meta.xml` 会导致部署失败；切勿留下重复或截断的元素
仅推送工作项的功能分支	解决方案属于工作项的分支；切勿直接推送到阶段/集成分支
此技能不执行提升或部署操作	解决操作的终点是推送无冲突的分支或完成诊断；提升操作（包括完整提升）由 `dx-devops-promote` 执行
使用脚本诊断部署失败，而非手动查看	`scripts/diagnose-deploy-failure.sh` 会确定性地归类失败原因，并通过 `git show` 验证分支上是否存在组件
仅当缺失组件存在于功能分支上时，才建议执行完整提升	如果组件不存在，提升分支无法提供该组件——重新提升只会再次失败

Gotchas

常见问题

Issue	Resolution
No `sf devops conflict` CLI command exists	DevOps Center conflicts are Git conflicts — resolve them with `git` , not a `sf devops` subcommand. This skill is git-based by design
Dirty working tree	`git status --porcelain` must be empty; instruct the user to commit or stash before detecting/resolving
User gave a work item, not a branch	Resolve the work item to its feature branch first via `sf devops work-item` — see `references/git-conflict-resolution.md`
Non-zero script exit treated as clean	Exit `2` = conflicts, exit `1` = error. Only exit `0` is "safe to promote"
Committing with markers still present	Run `git diff --check` and confirm the `--diff-filter=U` list is empty before `git commit` ; leftover `<<<<<<<` / `>>>>>>>` markers corrupt metadata
`--ours` / `--theirs` reversed	When merging the target INTO the feature branch, `--ours` = feature branch, `--theirs` = target stage branch
Manually merged XML is malformed	Keep `-meta.xml` well-formed; do not duplicate elements. Re-check the file parses before staging
Detached HEAD / stale branch	`git fetch` first; check out the feature branch as a tracking branch before merging (the script fetches for you)
Conflict reappears after promotion still fails	The target branch moved; re-run detection against the current target branch and resolve again
Re-promoting a deploy failure without diagnosing	Run `scripts/diagnose-deploy-failure.sh` first: exit `0` = component on the branch, a full promotion fixes it; exit `2` = it's a merge conflict (switch tracks); exit `3` = component absent, add and commit it (or include the owning work item) before promoting — promotion alone cannot supply it

问题	解决方法
不存在 `sf devops conflict` CLI命令	DevOps Center冲突属于Git冲突——使用 `git` 命令解决，而非 `sf devops` 子命令。此技能基于git设计
工作树不干净	`git status --porcelain` 必须为空；指导用户在检测/解决前先提交或暂存更改
用户提供的是工作项而非分支	通过 `sf devops work-item` 将工作项解析为对应的功能分支——参考 `references/git-conflict-resolution.md`
将非零脚本退出码视为干净状态	退出码 `2` =存在冲突，退出码 `1` =错误。只有退出码 `0` 表示“可安全提升”
提交时仍存在标记残留	在 `git commit` 前运行 `git diff --check` 并确认 `--diff-filter=U` 列表为空；残留的 `<<<<<<<` / `>>>>>>>` 标记会损坏元数据
`--ours` / `--theirs` 使用颠倒	将目标分支合并到功能分支时， `--ours` =功能分支， `--theirs` =目标阶段分支
手动合并的XML格式错误	保持 `-meta.xml` 格式正确；不要重复元素。暂存前重新检查文件是否可解析
分离HEAD状态 / 分支过时	先执行 `git fetch` ；合并前检出功能分支作为跟踪分支（脚本会自动拉取代码）
解决冲突后提升操作仍失败，冲突再次出现	目标分支已更新；针对当前目标分支重新运行检测并解决冲突
未诊断就重新提升部署失败的操作	先运行 `scripts/diagnose-deploy-failure.sh` ：退出码 `0` =组件在分支上，完整提升可修复；退出码 `2` =合并冲突（切换流程）；退出码 `3` =组件缺失，添加并提交后（或包含其所属工作项）再提升——仅提升无法解决问题

Output Expectations

输出预期

This skill produces a conflict-free feature branch or a deploy-failure diagnosis, not org changes:

No conflicts: confirmation that the feature branch merges cleanly into the target stage branch — safe to promote
Conflicts resolved: a merge commit on the work item's feature branch reconciling it with the target stage branch, pushed to the remote, plus a report of which files were resolved and how (took a side vs. manual merge)
Deploy-failure diagnosis: a report stating the failure reason (merge conflict / missing dependency in-branch / missing dependency not-in-branch / unrecognized), whether a full promotion can fix it, the missing component and where it lives, and the concrete next step

No metadata is deployed and no org state is mutated. The deliverable is the pushed, conflict-free branch or the diagnosis and recommended next step.

此技能会生成无冲突的功能分支或部署失败诊断结果，不会修改组织状态：

无冲突：确认功能分支可干净地合并到目标阶段分支——可安全提升
冲突已解决：工作项功能分支上的合并提交，使其与目标阶段分支保持一致，并推送到远程仓库，同时报告已解决的文件及解决方式（选择某一方版本或手动合并）
部署失败诊断：报告失败原因（合并冲突/分支内缺失依赖/分支外缺失依赖/无法识别）、完整提升是否可修复问题、缺失组件及其位置，以及具体的下一步操作

不会部署元数据或修改组织状态。交付成果是推送后的无冲突分支，或诊断结果及建议的下一步操作。

Cross-Skill Integration

跨技能集成

When	Action
The branch is conflict-free (or resolved and pushed) and ready to advance	Delegate to `dx-devops-promote` to validate and promote
A work item name/ID must be resolved to its feature branch, or candidate work items listed	Use `dx-devops-work-item-manage`
Work items share metadata and could promote as one unit instead of resolving separately	Consider combining via `dx-devops-promote` 's combine step rather than a manual merge
A promote deploy already failed on a conflict	Re-detect against the current target branch, resolve, push, then re-promote via `dx-devops-promote`
Diagnosis says a full promotion can fix the failure ( `dependency_in_feature_branch` )	Hand off to `dx-devops-promote` to run the full promotion — this skill does not promote
Missing component must be added to the feature branch before promoting	Author/commit the component (or include the owning work item) — for metadata generation use the relevant domain skill, then re-promote via `dx-devops-promote`

场景	操作
分支无冲突（或已解决并推送）且准备推进	委托给 `dx-devops-promote` 进行验证和提升
需要将工作项名称/ID解析为对应的功能分支，或列出候选工作项	使用 `dx-devops-work-item-manage`
工作项共享元数据，可合并为一个单元提升而非单独解决冲突	考虑通过 `dx-devops-promote` 的合并步骤进行合并，而非手动合并
提升部署已因冲突失败	针对当前目标分支重新检测，解决冲突，推送，然后通过 `dx-devops-promote` 重新提升
诊断结果显示完整提升可修复失败（ `dependency_in_feature_branch` ）	移交到 `dx-devops-promote` 执行完整提升——此技能不执行提升操作
提升前必须将缺失组件添加到功能分支	创建/提交组件（或包含其所属工作项）——元数据生成使用相关领域技能，然后通过 `dx-devops-promote` 重新提升

Reference File Index

参考文件索引

File	When to read
`scripts/detect-conflicts.sh`	Phase 2 — run it to non-destructively detect merge conflicts between the feature branch and the target stage branch
`scripts/diagnose-deploy-failure.sh`	Phase D — run it to classify a promotion deploy failure and decide whether a full promotion (or a missing-dependency fix) resolves it
`references/git-conflict-resolution.md`	When you need the full git command reference, the `sf devops work-item` -to-branch lookup, or `--ours` / `--theirs` and XML-merge guidance
`references/deploy-failure-resolution.md`	Phase D — when you need the deploy-failure decision tree, the error-parsing patterns, or the full-promotion reasoning behind the diagnosis script
`examples/conflict-workflows.md`	When the user's request matches a common pattern (pre-promotion conflict check, take-a-side resolution, manual XML merge, troubleshooting a failed promotion, or diagnosing a deploy failure)

文件	阅读时机
`scripts/detect-conflicts.sh`	阶段2——运行此脚本以非破坏性方式检测功能分支与目标阶段分支之间的合并冲突
`scripts/diagnose-deploy-failure.sh`	D阶段——运行此脚本以归类提升部署失败的原因，并判断是否可通过完整提升（或修复缺失依赖项）解决
`references/git-conflict-resolution.md`	当需要完整的git命令参考、 `sf devops work-item` 到分支的查询方法，或 `--ours` / `--theirs` 及XML合并指导时
`references/deploy-failure-resolution.md`	D阶段——当需要部署失败决策树、错误解析模式或诊断脚本背后的完整提升逻辑时
`examples/conflict-workflows.md`	当用户的请求符合常见模式（提升前冲突检查、选择某一方版本解决、手动XML合并、故障排查失败的提升操作、诊断部署失败）时