企业官网建设流程全解析

✅ No Conflicts

【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon

PR #{number} has no merge conflicts. It's ready for review/merge.

### 1.3 建立本地分支 获取 head 与 base 分支名，拉取最新代码并切换到 PR 分支： ```bash # Get branch info PR_HEAD=$(gh pr view {number} --json headRefName --jq '.headRefName') PR_BASE=$(gh pr view {number} --json baseRefName --jq '.baseRefName') # Fetch latest git fetch origin $PR_BASE git fetch origin $PR_HEAD # Checkout the PR branch git checkout $PR_HEAD git pull origin $PR_HEAD

本阶段结束前必须通过检查点（Checkpoint），确保后续操作的前提成立：

PHASE_1_CHECKPOINT:

• PR identified with conflicts
• Branches fetched
• On PR branch locally

Phase 2：ANALYZE —— 理解冲突

2.1 通过 Rebase 暴露冲突

命令选择git rebase而非git merge来暴露冲突——rebase 会把 PR 的提交逐一重放到 base 分支之上，在每个冲突提交处停下，这为逐提交解决提供了天然粒度：

git rebase origin/$PR_BASE

rebase 会在第一个冲突处停止，需要仔细阅读输出。

2.2 列出冲突文件

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

--diff-filter=U精确筛选出处于 "unmerged" 状态的文件，即所有存在冲突的文件。

2.3 逐个分类冲突

对每个冲突文件，先查看冲突标记：

# Show the conflict markers git diff --check cat {file} | grep -A 10 -B 2 "<<<<<<<"

随后按以下分类体系归类，分类直接决定处理策略：

2.4 读取两侧版本

对于复杂冲突，必须理解双方各自想做什么。git 在冲突时会把三个阶段对象存入索引，用git show配合阶段编号读取：

# Show base version (common ancestor) git show :1:{file} 2>/dev/null || echo "File didn't exist in base" # Show "ours" version (HEAD/current branch) git show :2:{file} # Show "theirs" version (incoming from base branch) git show :3:{file}

• :1:—— 共同祖先版本；
• :2:—— "ours"，即当前 HEAD（PR 分支）的版本；
• :3:—— "theirs"，即来自 base 分支的版本。

对不存在的文件（如某侧新增了文件），git show会失败，命令用2>/dev/null静默并提示。

PHASE_2_CHECKPOINT:

• All conflicting files identified
• Each conflict categorized
• Both sides' intent understood

Phase 3：RESOLVE —— 解决冲突

3.1 自动解决简单冲突

对意图清晰的冲突，命令定义了四条自动解决规则：

1. 双方各自新增了不同内容→ 同时保留两处新增；
2. 一方更新、另一方未触碰→ 保留更新的一侧；
3. 导入语句（import）冲突→ 合并两份导入列表；
4. 注释变更→ 优先保留信息更丰富的一版。

# For each auto-resolvable file # Edit to keep both changes (if both are additive) # Or keep the appropriate side based on intent

3.2 为复杂冲突呈现选项

当冲突需要人类决策时，命令要求 AI 输出结构化的选项对比，而不是直接把某个版本塞进文件。选项模板如下：

## Conflict in `{file}` **Lines {start}-{end}** ### Option A: Keep PR Changes (HEAD) ```{language} {code from PR branch}

What this does: {explanation of PR's intent}

Option B: Keep Base Branch Changes

{code from base branch}

What this does: {explanation of base branch's intent}

Option C: Merge Both (Recommended if compatible)

{merged version if possible}

Why: {explanation of why this merge makes sense}

Option D: Custom Resolution Needed

The changes are incompatible. Manual review required.

最后必须给出推荐与理由： ```markdown **Recommendation**: Option {X} **Reasoning**: {why this option based on: - Code functionality - PR intent from title/description - Which change is more recent/complete - Impact on other code}

四条判断依据覆盖了功能正确性、PR 意图、变更新鲜度与影响面四个维度，确保推荐可追溯、可质疑。

3.3 应用解决方案

对每个冲突：自动可解的直接应用；需要决策的采用推荐选项（若仍不清晰则询问用户）。每编辑完一个文件立即暂存：

# After editing each file git add {file}

3.4 继续 Rebase

# After resolving all conflicts in current commit git rebase --continue

如果有多个提交冲突，rebase 会依次停下，重复上述解决流程。

PHASE_3_CHECKPOINT:

• All simple conflicts auto-resolved
• Complex conflicts resolved with documented reasoning
• All files staged
• Rebase completed

Phase 4：VALIDATE —— 验证解决方案

合并冲突解决后绝不能直接推送，必须过四道验证关卡：

4.1 检查无残留冲突标记

git diff --check

应返回空——即文件中不再存在冲突标记。git diff --check会同时报告空白错误与未解决的冲突标记，是一个低成本高价值的快速门禁。

4.2 类型检查

bun run type-check

如果类型错误与本次解决相关，必须修复。注意这里使用bun run type-check，与本仓库 package.json 中的脚本约定一致（Archon 本身是 Bun 技术栈）。

4.3 运行测试

bun test

若测试因本次解决而失败，需要调查并修复。

4.4 Lint 检查

bun run lint

修复所有 lint 问题。

PHASE_4_CHECKPOINT:

• No conflict markers remaining
• Type check passes
• Tests pass
• Lint passes

Phase 5：PUSH —— 更新 PR

5.1 强制推送已解决的分支

由于 rebase 重写了提交历史，必须强制推送：

git push --force-with-lease origin $PR_HEAD

命令特意强调：--force-with-lease比--force更安全——它会在远端被他人推送过新提交时拒绝推送并报错，避免覆盖队友的工作。

5.2 验证 PR 可合并

gh pr view {number} --json mergeable,mergeStateStatus

应显示MERGEABLE。

PHASE_5_CHECKPOINT:

• Branch pushed successfully
• PR shows as mergeable

Phase 6：REPORT —— 记录解决方案

6.1 生成解决报告产物

命令要求把完整解决过程写入$ARTIFACTS_DIR/../reviews/pr-{number}/conflict-resolution.md（目录不存在则创建）。报告模板结构如下：

# Conflict Resolution: PR #{number} **Date**: {ISO timestamp} **Branch**: {head} rebased onto {base} ## Summary Resolved {N} conflicts in {M} files. ## Conflicts Resolved ### File: `{file1}` **Conflict Type**: {SIMPLE_ADDITION | SAME_LINES | etc.} **Resolution**: {Auto-resolved | Option A/B/C chosen} **Before (conflict)**: ```{language} <<<<<<< HEAD {head version} ======= {base version} >>>>>>> {base}

After (resolved):

{final code}

Reasoning: {why this resolution}

File:{file2}

{Same structure...}

Validation

Git Log

{git log --oneline -5}

Metadata

• Resolved by: Archon
• Timestamp: {ISO timestamp}

这份产物同时满足三个目的：可审计（记录了 before/after 与理由）、可复现（含 git log）、可作为下游步骤的输入。这正对应 [命令编写指南](https://link.gitcode.com/i/1f67b4189a813114fc24f533cf92866a) 中"产物即下一步的规格说明"的核心原则——多步骤工作流中 Agent 之间没有共享记忆，文件是唯一的沟通渠道。 ### 6.2 在 PR 上发布评论 用 `gh pr comment` 配合 heredoc 向 PR 发布结构化评论，让协作者无需进入产物目录就能了解全貌： ```bash gh pr comment {number} --body "$(cat <<'EOF' ## ✅ Conflicts Resolved **Rebased onto**: `{base}` **Conflicts resolved**: {N} in {M} files ### Resolution Summary | File | Conflict Type | Resolution | |------|---------------|------------| | `{file1}` | {type} | {resolution approach} | | `{file2}` | {type} | {resolution approach} | ### Validation ✅ Type check | ✅ Tests | ✅ Lint ### Details See `$ARTIFACTS_DIR/../reviews/pr-{number}/conflict-resolution.md` for full resolution details. EOF )"

PHASE_6_CHECKPOINT:

• Artifact created
• GitHub comment posted

Phase 7：OUTPUT —— 最终报告

命令以一份面向用户的最终摘要收尾，覆盖结论、明细、验证结果与后续动作：

## ✅ Conflicts Resolved **PR**: #{number} - {title} **Branch**: `{head}` rebased onto `{base}` ### Summary - **Files with conflicts**: {M} - **Conflicts resolved**: {N} - **Auto-resolved**: {X} - **Manual decisions**: {Y} ### Resolution Details | File | Type | Resolution | |------|------|------------| | `{file}` | {type} | {approach} | ### Validation | Check | Status | |-------|--------| | Type check | ✅ | | Tests | ✅ | | Lint | ✅ | ### Artifacts - Resolution details: `$ARTIFACTS_DIR/../reviews/pr-{number}/conflict-resolution.md` ### Next Steps 1. Review the resolution if needed: `git log -p -1` 2. PR is now ready for review 3. Request review: `@archon review this PR`

git log -p -1用于人工复核最后一次提交的完整 diff，将 AI 的解决过程暴露给人类审查者，形成人机协作的闭环。

错误处理：三条常见失败路径

再完善的流程也会失败。命令针对三种高频故障给出了明确预案：

Rebase 中途失败

若某个提交无法解决：

# Check status git status # If truly stuck, abort and report git rebase --abort

【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon